SitePoint Sponsor

User Tag List

Page 3 of 4 FirstFirst 1234 LastLast
Results 51 to 75 of 81
  1. #51
    Anonymous
    SitePoint Community Guest
    Great article.
    Thank you.
    Brazilian user.

  2. #52
    SitePoint Enthusiast scriptsmiths's Avatar
    Join Date
    Aug 2003
    Location
    South Africa
    Posts
    34
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice article! One comment, don't rely on size/maxlength tags in your HTML to limit length of user input. No client-side validation tactics are secure. Check the length of the input in your script code, it is very easy for an attacker to bypass client-side input validation.

  3. #53
    Anonymous
    SitePoint Community Guest
    What about stored procedures??? It's much less likely to succeed if all your SQL code is in stored procedures (which offer numerous other benefits as well).

  4. #54
    Anonymous
    SitePoint Community Guest
    Hi,
    I don't agree "killChars" function. Just think that some user has registered with the password "xp_username1" ... Applying your funtions, he will never be able to connect since you modify his login before testing in db.

    I think that stripQuotes is enough for the purpose.

    Thanks,
    Adi Muraru. Romania

  5. #55
    Anonymous
    SitePoint Community Guest
    Finally I have understood, what SQL injection is about, and I can also seee the solution to this problem, as well.

  6. #56
    Anonymous
    SitePoint Community Guest
    nice article. was very educative and helped me to be more cautious towards the way we write scripts

  7. #57
    Anonymous
    SitePoint Community Guest
    "Hi, I don't agree "killChars" function. Just think that some user has registered with the password "xp_username1" ... Applying your funtions, he will never be able to connect since you modify his login before testing in db. I think that stripQuotes is enough for the purpose. Thanks, Adi Muraru. Romania"

    If you strip quotes at time of registration or notify him that his password contains invalid characters, then it should be fine.
    - Chris Pilkington http://dev.iluo.net

  8. #58
    Anonymous
    SitePoint Community Guest
    What about using parameterized queries or stored procs instead?

  9. #59
    Anonymous
    SitePoint Community Guest
    hi,
    its nice article though there are some comments on killChars functions and all...But by this you have provided us with a note to check for such attacks.

    At the end of the day it was informative And i liked it.

  10. #60
    Anonymous
    SitePoint Community Guest
    This was a decent article for a newber but most of them don't worry about security until it is too late. I was lucky enough to have someone tell me to use the mysql_escape_string() function in php before I released my first mysql based product. It was an overall pretty good job.
    -FIE

  11. #61
    Anonymous
    SitePoint Community Guest
    Are you guys joking with me? I don't know if it's just me or... OFCOURSE you need to parse any string you plan to append to a sql query with a function like the stripQuotes function. (The name of that function should maybe not be just stripQuotes though, since it implies that you actually are stripping the quotes (removing them) from the string instead of actually escaping them with the correct escape sequence which just happens to be '' double quotes for each ' single quote. viola!) Please don't forget that just because you are starting of with a String from the querystring and are in the end creating another String fo the sql-query it doesn't mean that you can skip the whole parsing step. Lets say you are fetching param with name "id" and expecting it to be an integer then you must call a function like stringToInteger and handle any errors that would occur if someone tried to tamper with your parameter sending you a string that don't assembles a integer and so on. Other than that you must ofcourse escape the params to their sql equivalent when adding them back to the sql-query. In strings ' escapes to '' and so on. (Please remember that depending on the database vendor other datatypes might also need to be escaped like sometimes true (boolean) escapes to 1 or dateformat to another and so on) To just brutally concatenate or append any stringparameter you get from a browser feed directly to a sql query, if its from the qs-params or form-params, would be like buying a tv-set, unpacking it whith closed eyes and put the socket into the wall without actually noticing that the guy in the store gave you a toaster instead. Noone can afford to be that lazy while coding! To use any form of the killChars (again with the name) function though I can't see the point of other than annoying the enduser that his supplied string did not go into the code the way he entered it and implies that the programmer just don't trust his or hers own escape functions to work for protection. I just hate those sites that tells me that I can't use some characters for my password since everybody knows that the best way to enforce a password security is to use special characters in them because it makes it more difficult to guess for the hackers. I'm sorry but I don't know if this entire article need to be longer than. "Hey guys, I thrust that you don't forget to parse the parameters into the datatypes you are expecting them to be before concatenating them into your sql-querys." That's it! ok maybe I could add another line "Also remember to escape the ' char with ''.". I could not find a creationdate for this article but I really hope it was written in like the early 90's or so otherwize this is just to scary for me...

  12. #62
    Dumb PHP codin' cat
    Join Date
    Aug 2000
    Location
    San Diego, CA
    Posts
    5,460
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Whats scarier is you spent how many minutes you spent writing a reply to a thread that was started over a year ago about an article that is almost a year and a half old.
    Please don't PM me with questions.
    Use the forums, that is what they are here for.

  13. #63
    Database Jedi MattR's Avatar
    Join Date
    Jan 2001
    Location
    buried in the database shell (Washington, DC)
    Posts
    1,107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    And didn't bother to use indentation/new lines for easy readability.

  14. #64
    Free your mind Toly's Avatar
    Join Date
    Sep 2001
    Location
    Panama
    Posts
    2,181
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    And didn't bother to use indentation/new lines for easy readability.
    It hurt my eyes.
    Community Guidelines | Community FAQ

    "He that is kind is free, though he is a slave;
    he that is evil is a slave, though he be a king." - St. Augustine

  15. #65
    Anonymous
    SitePoint Community Guest
    Great article!, really interesting. but would be usefull to give to protect from PHP too, not only ASP..

  16. #66
    Anonymous
    SitePoint Community Guest
    good ending

  17. #67
    Anonymous
    SitePoint Community Guest
    Quite usefull to hack this site also. But I m not able to do. Can anybody guide me? Rahul (reachrahulz@yahoo.com)

  18. #68
    Anonymous
    SitePoint Community Guest
    Good article, couple of points:

    Getting rid of "drop" and "select" might be a nuisance if the input forms part of a content management system or similar where users need to input long descriptions etc. in which those words might occur quite innocently.

    One way around this is to give all your database objects a prefix that can be safely replaced to prevent any actions being performed on them, for example: tblMySiteUsers, tblMySiteProducts etc. You can then safely replace "tblMySite" with an empty value so that should an attacker discover the table name and try: "DROP TABLE tblMySiteUsers" it becomes: "DROP TABLE Users", the table "Users" doesn't exist so the attack fails.

    One last thing, you should modify the Replace command slightly, in your example you have used a binary comparison:
    newChars = replace(newChars, badChars(i), "")

    Binary comparisons are case sensitive, so while it will protect you from "drop" and "select", "DROP" and "SELECT", which are valid SQL, will get through. Use a text comparison instead this will get rid of the character string regardless of case, for example:

    newChars = replace(newChars, badChars(i), "", 1, -1, 1)

  19. #69
    Anonymous
    SitePoint Community Guest
    in regards to limitting argument length, making your web forms shorter is insufficient. any user with a moderate level of skill could enter parameter's of any length in the url, or copy the html to their drive, modify it as the please, and use that to submit to your script.

    always have the backend script itself limit argument size... this is done simply in most languages

  20. #70
    SitePoint Member
    Join Date
    Jun 2002
    Location
    currently Chester County, PA, US
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why not just trap for spaces? No username or password should have them.

  21. #71
    Anonymous
    SitePoint Community Guest
    This article was very informative and timely. Thank you for making this available to the public because I'm sure you've probably saved many sites from attack by providing this kind of help.

  22. #72
    Anonymous
    SitePoint Community Guest
    stripQuotes and killChars "seem" to be a good idea but you don't specify where exactly we need to use them.

    Using them when executing a query basically, as you say, render them useless. So I understand where stripQuotes can be useful but where do we call killChars?

  23. #73
    Anonymous
    SitePoint Community Guest
    Don't you see that all of these problems caused by sa and blank password? so why not just use built-in SQL security system?

  24. #74
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,625
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    SA is part of the built in SQL server security model. Having a blank (or weak) SA password is a big no-no, even on a development server.

    Another big problem is folks who develop apps using the SA as the web user. Policy here is that users cannot access tables directly, much less run XP_Procs or do modify DB objects. They are all routed through Stored Procs, UDFs and Views depending on what needs being done. It is very effective at precluding many of these security issues.

    WWB

  25. #75
    Anonymous
    SitePoint Community Guest
    It is always a good idea to configure your webserver to not display script errors when you are finished debugging the page and it goes into production. Users should see a custom error page, rather than the one generated by the script error. You can then direct the user to a method of reporting the error, or give some other method of allowing the user to finish what they were legitimately doing, while giving no information to the would-be hacker.


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
  •