Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 2 12 LastLast
Results 1 to 15 of 30
  1. #1
    Regular Coder
    Join Date
    Sep 2007
    Posts
    238
    Thanks
    9
    Thanked 0 Times in 0 Posts

    Search results, pagination and SQL injections

    Hi all,

    I'm working on a database keyword search. Up until now, I'm been using the POST method so that all details from the form are not shown in the URL.
    Everthing is escaped and validated so I'm pretty sure its protected against SQL injection.

    I'm now adding pagination to the results which appends offset= to the URL to go to the correct page. The problem is I then loose the keywords from the form as they are not in the URL.

    So from my (limited) understanding, I either need to sent the offset as form data along with the keywords, or change the keywords to GET and have everything visible in the URL.

    If all data is escaped and validated, is the GET method safe or should I always use forms/POST?


  • #2
    Regular Coder
    Join Date
    Dec 2009
    Location
    UK
    Posts
    495
    Thanks
    0
    Thanked 58 Times in 58 Posts
    The GET method is fine, and many search engines use it (Google does for example)
    My site: JayGilford.com
    Resources:
    PHP Pagination Class | Getting all page links | Handling PHP Errors properly
    If you like a users help, show your appreciation with the rep and thanks buttons :)

  • #3
    Regular Coder
    Join Date
    Mar 2006
    Posts
    238
    Thanks
    3
    Thanked 37 Times in 37 Posts
    All data must be escaped and validated. POST is not more secure than GET.

    Yes, you would need to use GET for your search. Advantage: users would be able to bookmark search result pages. All major search engines use GET at the search pages.

    Or you would need to use a JavaScript, which would submit a form by POST when one of your page hyperlinks (I mean page numbers 1, 2, 3... which are usually shown as hyperlinks below the search results) is clicked. Disadvantage: pagination would not work if JavaScript is turned off in the user browser.

    Edit: JAY6390 has been quicker to answer

    Edit2: When I said POST is not more secure than GET, I meant for SQL injection attacks of course. I mean there is not much difference for a hacker to send a POST or GET to the site. Still of course if some sensitive information is sent (like e.g. passwords), GET should never be used. Because GET request sends parameters via an URL which could be cached in the browser history, in server logs (some server cuold be so badly configures that their logs could be publicly accessed, etc.)
    Last edited by SKDevelopment; 02-08-2010 at 11:38 AM.

  • #4
    Regular Coder
    Join Date
    Sep 2007
    Posts
    238
    Thanks
    9
    Thanked 0 Times in 0 Posts
    Thanks both.
    Thats what I was thinking too, but always nice to get a bit of reassurance

  • #5
    Regular Coder
    Join Date
    Mar 2006
    Posts
    238
    Thanks
    3
    Thanked 37 Times in 37 Posts
    It is a pleasure.

    Just in case: I have added a small edit (Edit2) to the post to explain my point on GET/POST security a little bit more in detail. Sorry for not providing this explanation at once. I'll try to pay more attention to such things in the future.

  • #6
    Regular Coder
    Join Date
    Sep 2007
    Posts
    238
    Thanks
    9
    Thanked 0 Times in 0 Posts
    Thanks SKDevelopment.
    I'm using http_build_query($_GET); to replace the offset for the new page links.

    Do I need to do any validation/sanitising before rebuilding the url?
    Each parameter gets validated/sanitised before going into the sql query, so I dont know if the checks need to be done at every stage that form data is used or just the once (before the sql).

  • #7
    Regular Coder
    Join Date
    Mar 2006
    Posts
    238
    Thanks
    3
    Thanked 37 Times in 37 Posts
    You need to validate/sanitize before using parameters in the queries. You also need to apply htmlspecialchars() or htmlentities() to the HTML output to avoid HTML injections ... Shortly speaking it is absolutely necessary to validate/sanitize any input (from any source) before using it in any way.

    But personally (I could be wrong of course) I do not see any great need to validate parameters specially for use in http_build_query(). At least I would not do that. But this is my personal opinion only of course which could be wrong.

  • #8
    Regular Coder
    Join Date
    Sep 2007
    Posts
    238
    Thanks
    9
    Thanked 0 Times in 0 Posts
    all very useful info... there's so much to learn!

  • #9
    New Coder
    Join Date
    Mar 2009
    Posts
    90
    Thanks
    5
    Thanked 14 Times in 14 Posts
    Hi,

    As an appendix to this thread, you can use .htaccess to validate input and make SEO friendly URLs both in the same time!
    Regards

  • #10
    Regular Coder
    Join Date
    Mar 2006
    Posts
    238
    Thanks
    3
    Thanked 37 Times in 37 Posts
    Quote Originally Posted by htcilt View Post
    all very useful info... there's so much to learn!
    Yes, security is very interesting and very important thing to learn for sure. I agree completely. SQL injections, mail injections, HTML injections, file injections, session fixation and session hijacking attacks, XSS etc. All that is absolutely necessary to know for a web-programmer... And I never saw any one source with a lot of data on this subject where it was described well. I had to google on many questions, read it from different sources/articles on the Internet. Forums always have been especially useful for learning too.

    If someone asked me about a good book on PHP, I could recommend the official Zend guide for preparation for the Zend Certified Engineer test (maybe not to start learning but must-read for sure). But with web-security, probably it is better learned from on-line articles. At least I did not see any really good books on this subject so far ... Maybe someone else did though ...
    Last edited by SKDevelopment; 02-09-2010 at 01:06 PM.

  • #11
    Regular Coder
    Join Date
    Sep 2007
    Posts
    238
    Thanks
    9
    Thanked 0 Times in 0 Posts
    I've done a bit of reading on htmlentities. Its a little confusing.
    At present I just have a form that searches the database by the entered keyword.

    For example if I do:
    PHP Code:
    $message 'Your search for <strong>'.$orig_keyword.'</strong> found the following <strong>'.$rowcount_array[0].'</strong> results:<br />';

    echo 
    htmlentities($messageENT_QUOTES); 
    I get the following on screen
    Code:
    Your search for <strong>house</strong> found the following <strong>8</strong> results:<br />
    Obviously I wouldn't want html to be literally displayed on screen, so I'm a little confused at which point in my code (html form, sql and results all on the same page) I need to be using htmlentities?
    I have read several articles online but I'm still not understanding

  • #12
    Senior Coder Dormilich's Avatar
    Join Date
    Jan 2010
    Location
    Behind the Wall
    Posts
    3,237
    Thanks
    12
    Thanked 340 Times in 336 Posts
    Quote Originally Posted by htcilt View Post
    Obviously I wouldn't want html to be literally displayed on screen, so I'm a little confused at which point in my code (html form, sql and results all on the same page) I need to be using htmlentities?
    htmlentities is for preventing HTML code to be parsed as HTML (i.e. preventing HTML injection attacks). usually, it is used on input validation or on places, where you need to prevent HTML injection.
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    André Behrens, NY Times Software Developer

  • #13
    Regular Coder
    Join Date
    Sep 2007
    Posts
    238
    Thanks
    9
    Thanked 0 Times in 0 Posts
    Ah its slowly falling into place (I think!).

    Up until now I've been using preg_replace strip out special characters before including in the sql e.g.

    PHP Code:
    $the_keyword=preg_replace('/[^0-9a-z ]+/i'' '$the_keyword); 
    Is this method along enough or do I need to use htmlentities in addition (before inserting into SQL)?
    I've started changing all my echoed strings/variables to htmlentities.

    One snag with htmlentities so far (when applied to the search keyword) is it strips out apostophes which need to stay in.

  • #14
    Senior Coder Dormilich's Avatar
    Join Date
    Jan 2010
    Location
    Behind the Wall
    Posts
    3,237
    Thanks
    12
    Thanked 340 Times in 336 Posts
    what is that code doing, doesn’t make any sense to me?

    EDIT: well it does now, but what’s the intention? a replacement for strip_tags()?
    Last edited by Dormilich; 02-09-2010 at 02:57 PM.
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    André Behrens, NY Times Software Developer

  • #15
    Regular Coder
    Join Date
    Sep 2007
    Posts
    238
    Thanks
    9
    Thanked 0 Times in 0 Posts
    Sorry, I wasn't being very clear.

    I have a form that has an input text box. The user types in a keyword and this is searched for in the database.
    The results are echoed along with the keyword searched for

    I want to protect $the_keyword but I'm not clear on what to use and when to use it.

    I have:
    PHP Code:
    echo 'Your search for <strong>'.htmlentities($the_keywordENT_QUOTES'UTF-8').'</strong> found the following'
    This seems to work ok.

    But then there is:
    PHP Code:
    $the_keyword $_GET['keyword']; 
    I'm not sure how to protect it but without stipping out characters that are needed such as apostrophes?

    I really appreciate everyones help - I realise this is all very n00b!


  •  
    Page 1 of 2 12 LastLast

    Posting Permissions

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