SitePoint Sponsor

User Tag List

Results 1 to 12 of 12
  1. #1
    SitePoint Zealot
    Join Date
    May 2008
    Posts
    165
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Secure Session Based Login

    Hi all,
    I just read this article: http://thedailywtf.com/Articles/Well...struction.aspx and the long and short of it said don't design your site to be secure using the header() function in PHP, specifically, header(Location: blah) if a user fails the login procedure. This got me thinking, is it secure? The article seems to think not, and I use a similar login structure for a web app, just with die(); contained in the if statement too, so if the header isn't followed, then they can't go anywhere else.
    This also got me thinking, why does everyone always act upon the user not being logged in? If it was such a great problem, rather than a one line if statement at the top of every page, if each and every page was enclosed in an if statement, and only displayed if true? That is, the header() becomes part of the else statement at the end? Or even better, have a function that takes care of this for us.

    So, ideas, comments?

  2. #2
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Keep that in mind when designing your systems; use <input type="button" value="Delete Something" />, not <a href="delete.php?deleteWhat=everything&deleteMode=unrecoverable">index me!</a>. And maybe don't use just the Location header to secure your site.
    This final line bothers me. It is an example of using a html form GET method to DO something - which breaks the idea of that part of the protocol.

    Altering the state of something should be done using POST, GET should do just that, retrieve information.

    That was fairly typical of the kind of kludged thinking and developing you come across in many old projects.

    Sending readers away without this solid cornerstone of advice ringing in their ears is a bad mistake in my book, so I guess the rest of the article is just as lightweight - so didn't read it.

  3. #3
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,194
    Mentioned
    17 Post(s)
    Tagged
    5 Thread(s)
    Keep that in mind when designing your systems; use <input type="button" value="Delete Something" />, not <a href="delete.php?deleteWhat=everything&deleteMode=unrecoverable">index me!</a>. And maybe don't use just the Location header to secure your site.
    That doesn't make sense because you can easily secure that location or set of get vars just as easily as you could using a submit.

    I normally do something like:

    /index.php/delete-whatever/3/

    However, the controller that links to delete-whatever can only be accessed via admins or a user with the appropriate permissions.

  4. #4
    Twitter: @AnthonySterling silver trophy AnthonySterling's Avatar
    Join Date
    Apr 2008
    Location
    North-East, UK.
    Posts
    6,111
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    I think Cups was merely stating that this breaks the intended purpose of the HTTP protocol.
    @AnthonySterling: I'm a PHP developer, a consultant for oopnorth.com and the organiser of @phpne, a PHP User Group covering the North-East of England.

  5. #5
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by oddz
    However, the controller that links to delete-whatever can only be accessed via admins or a user with the appropriate permissions.
    I agree you will probably have to do that, it makes compete sense.

    You can even build the permission to 'delete' at the database level (using the mysql permissions tables) which I do too on my CMS which sets up a different dbase for each client (multiple clients using the same base code, but with differing databases and templates).

    I just suffer the imagined horror of "internal hackers" who may some way find a way to delete things in others' systems - not just a wild indexing of a public page as that article rightly warns of.

    Another way of thinking is to not delete anything, just flag it as "no longer live", which may not suit every occasion, I thoroughly admit, but does offer the added bonus of "roll back".

    However you never know what security holes you are leaving, and its up to everyone to decide if it is OK to break the principle of using GET to change things, but everyone should just be doubly aware of the implications.

  6. #6
    PHP Guru lampcms.com's Avatar
    Join Date
    Jan 2009
    Posts
    921
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That article describes a problem that was caused by a moron writing his first script.
    Just reading it is a waste of time.

  7. #7
    SitePoint Wizard
    Join Date
    Mar 2008
    Posts
    1,149
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Not only is that article describing a newbie problem, it's dead wrong.

    It's not because the redirect is not honored. It's because header() will not stop execution of the rest of the script.

    Even if an exit() was placed after the header redirect, the script would still be vulnerable to CSRF attacks. <input type="button" value="Delete Something" /> would not alleviate that exploit either.

    ...worse of all, it's written like a bad novel.

  8. #8
    SitePoint Zealot
    Join Date
    May 2008
    Posts
    165
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You guessed this was coming, but, how can we stop users having to worry about a CSRF attack? In other words, what can we do as web developers to stop anyone having this sort of problem? I thought CSRF was only in cookies, as sessions were deleted once the browser windows was closed, so a CSRF attack would have to gamble on the user having the window / tab open. Correct me if I'm wrong, but that's what a PHP book I have lying here told me about sessions ;-)

  9. #9
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You can embed a hidden unique id in the form, that your server generates upon displaying the form, and then checks and validates before processing the form submission. Checking the referer header can also be pretty effective, although it's not reliable, and cannot be depended on.

    As far as finding a victim who is logged in...it's not that difficult for many websites if you think about it. You could also persuade a user to log in with some clever social engineering.

  10. #10
    SitePoint Wizard
    Join Date
    Mar 2008
    Posts
    1,149
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    CSRF:
    HTML Code:
    <!-- GET -->
    <img src="http://www.example.com/delete.php?id=3234" alt="" />
    
    <!-- POST -->
    <iframe name="secret" src="about:blank" width="1" height="1" style="position: absolute; top: -999px"></iframe>
    <form action="http://www.example.com/delete.php" method="post" target="secret">
    <input type="hidden" name="id" value="3234" />
    </form>
    <script type="text/javascript">
    document.forms[0].submit();
    </script>

  11. #11
    SitePoint Zealot
    Join Date
    May 2008
    Posts
    165
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Very good point. So, essentially, I could just get PHP generating a random number, or random hash, and put it in my form, as a hidden field, or, a session element (as if it comes through the form, something about the form has to enable me to work back to my original 'thing' I generated. Does that sound about right?

  12. #12
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ya, you could just stick them in a session. Might wanna use an array so you could maintain multiple tokens(so users can have multiple browser windows open without interfering with the form submission process), although you could also just use the same token for all forms issued throught the users session if you like.


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
  •