SitePoint Sponsor

User Tag List

Results 1 to 9 of 9
  1. #1
    ********* Callithumpian silver trophy freakysid's Avatar
    Join Date
    Jun 2000
    Location
    Sydney, Australia
    Posts
    3,798
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I found this article quite intereting. http://www.webreview.com/2001/04_13/.../index02.shtml
    Your Webmaster is finally content. All of the hotfixes, service packs, and point releases for the Web server, operating system, database, and application server are in place. The firewall is in place and your network engineers are actively monitoring for attacks. You use long, cryptic passwords and rotate them frequently?your site is as secure as it could be, right? Maybe. But if you're using a development tool like ColdFusion, ASP, or PHP, your application developers have probably unknowingly opened holes directly into your database that could wreak havoc on your system. Not obscure, difficult-to-exploit holes, but real big delete-everything-from-the-database kind of holes. Today, we're going to discuss how those security holes arise and more importantly, how to plug them.
    Does anyone have some other links to articles or information to share on this topic?

  2. #2
    Hi there! Owen's Avatar
    Join Date
    Jan 2000
    Location
    CA
    Posts
    1,165
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well you can do a SQL command like (this is what they recommend in the SQL readme):

    my $sth = $dbh->prepare_cached("SELECT * FROM $table where id=?")
    or die "Couldn't prepare statement: " . $dbh->errstr;
    $sth->execute($id)
    or die "Can't exec statement: " . $sth->errstr;
    ...
    Now the problem mentioned above is impossible because SQL automatically quotes the data and checks it so that security holes like the one described are impossible. It seems like the article was being kind of alarmist. But holes DO exist are are a big problem so be careful!

    Owen

  3. #3
    SitePoint Zealot
    Join Date
    May 2000
    Posts
    150
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Basically, check for valid input from forms:

    eg: numbers only -> filter everything except 0-9
    Text -> filter everything except alphanumeric and allowed special characters

    I like to cut strings to their right size too. For example, if a column is declared as varchar(255), limit the size of the input to 255. Not necessary, but better to be safe.

    Add slashes (encode) all form input that is going to be placed in SQL statements. I think the SQL (12345678 TRUNCATE TABLE Items) in that article is MSSQL Server specific. In MSSQL Server, you don't have to seperate multiple SQL statements by a semicolon. With mysql, you have to seperate multiple SQL statements with a semicolon. If you filter your form input, ';' gets replaced by '\;' and doesn't harm anything.

    There are some other points, mostly relating to perl and files. Heres a nice list:

    http://www.shmoo.com/securecode/

    Cheers,

  4. #4
    Grumpy Mole Man Skunk's Avatar
    Join Date
    Jan 2001
    Location
    Lawrence, Kansas
    Posts
    2,066
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The thing about the TRUNCATE command was definitely an eye opener - I've always been slightly worried about people being able to feed nasty SQL to my database, that just proves me fear was correct...

    I reckon as long as you follow these two simple rules you can't go far wrong:

    1. Don't trust ANY information that comes from the net. Assume everything is written by some nasty minded person who has the source code to your entire site and plenty of time on their hands - if you can spot a possible security hole then fix it (never rely on security by obscurity) but even better make sure all passed information that could be remotely dangerous is stamped on.

    2. On a production site back up the databaser onto a different machine at least once every 24 hours, and keep a rolling update log as well. Then even if your security is breached and someone wipes out all your data you can restore the previous night's backup (and fix the security hole at the same time). This is what I plan to do on my first 'serious' (as in I'll get in severe trouble if it breaks) database driven application that I'm working on at the moment.

  5. #5
    SitePoint Addict mgkimsal's Avatar
    Join Date
    Sep 1999
    Posts
    209
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    doesn't work?

    If my SQL was
    select * from industryinfo where userid=$id

    and someone passed in "5 truncate table industryinfo" my SQL would look like

    select * from industryinfo where userid=5 truncate table industryinfo

    This throws an error in mysql. Haven't tried it yet in SQL server or others.

    Throwing a ; in there does the trick tho.

    if ID is "5; truncate table industryinfo" all bets are off...

    Unless your SQL is
    select * from industryinfo where userid="$id"

    But there's ways around that too...
    Michael Kimsal
    =============================
    groovymag.com - for groovy/grails developers
    jsmag.com - for javascript developers

  6. #6
    SitePoint Zealot
    Join Date
    May 2000
    Posts
    150
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: doesn't work?

    Is anyone interested in writing some sort of a FAQ/article on issues concerning PHP/Perl & mySQL: security, How to program "Next/Prev" navigational headers etc?

  7. #7
    SitePoint Addict mgkimsal's Avatar
    Join Date
    Sep 1999
    Posts
    209
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    articles?

    Perhaps articles about security would be OK, but the next/prev thing is, imo, done to death, and pretty damn easy to figure out. Multiple ways to do it, yes, and perhaps you won't choose the best one straight off, but that's where real learning comes in - not solely from articles from people who probably haven't done much more than yourself.
    Michael Kimsal
    =============================
    groovymag.com - for groovy/grails developers
    jsmag.com - for javascript developers

  8. #8
    SitePoint Zealot
    Join Date
    May 2000
    Posts
    150
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sure its been done to death... but what I meant was, some sort of a FAQ; a compilation of such questions and solutions from threads posted at sitepointforums.

    Would help quite a few people I'd think.

  9. #9
    SitePoint Wizard westmich's Avatar
    Join Date
    Mar 2000
    Location
    Muskegon, MI
    Posts
    2,328
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Let me jump in and maybe get this topic back on track

    The author mentions a possible security hole of allowing visitors to enter SQL commands into a form. I think another approach is creating a user specifically for your Web page and limiting it's privileges. Inserts, Updates, and especially Deletes should only be able to be done by trusted admins or members of a private area.

    This brings up another question, though. Let's say I build a Web page for a corporation so that employees can access benefits and stuff. The Database Admin creates an account for me to use in my code so that I can query the database. I use my assigned username and password in the code to access the employee records and save the page to the server. Questions:

    What's to stop someone from the IT department into looking into my code and learning the username and password?

    Should I lock this file down and only enable it through Web sharing? (this can be done in W2K, not sure about UNIX)

    Or would I just be better off to have the DBA create a stored procedure (provided the company is using a high-end database) and simply pass the form variables to the stored procedure?
    Westmich
    Smart Web Solutions for Smart Clients
    http://www.mindscapecreative.com


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •