#1
  1. A Change of Season
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2004
    Location
    Next Door
    Posts
    2,664
    Rep Power
    171

    What could be dangerous about this form?


    Hi;

    A lot to learn

    What are the threats here How can an attacker take advantage of this?

    Thank you
  2. #2
  3. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4123
    it doesn't print the submitted text back to the screen - this is good

    the string

    Code:
    ' or 1 = 1; --
    seems to be handled in a manor which suggests your backend protects against SQL injection, which is good

    should we take a view whether the "Invalid password" is a proper response? given a dictionary attack valid passwords are easily confirmed - so do you rate limit?

    What if I have this html on my site?

    html Code:
     
    <h3>Log into thetransporter</h3>
    <form action="http://thetransporter.com.au/index.php/log_in/do_log" method="post" accept-charset="utf-8">
         <input type="password" name="password" />
         <input type="submit" name="submit" value="Login" />      
    </form>


    It transparently redirects people to your site. Depending on the nature of the form I could trick people into filling in the form when they didn't want to, or I could have some javascript listening to the form and logging what people enter.

    The former is known as cross site request forgery, and can be protected against - you're not do this at the moment.

    I don't know what the name for the latter type is but all logins would fail if you protect against XSRF...althogh this doesn't protect against the listening and logging. For that you'd probably have to have randomly generated field names, matched via the anti xsrf token to a server side session. Tricky, against ReST and not 100% safe (think phishing)
    Last edited by Northie; July 2nd, 2013 at 04:41 AM. Reason: typos
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  4. #3
  5. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    @ Northie:

    I'm sorry, but what are you talking about? I think you've not quite understood cross-site request forgery.

    CSRF attacks are done on authenticated users. The whole point of this attack is to take advantage of the privileges of an authenticated user (see the OWASP).

    A "guest" by definition is safe from CSRF attacks, because they simply have no privileges. They have the same rights everybody has. You gain nothing from routing a request through them as opposed to doing it yourself.

    The attack you describe above has absolutely nothing to do with CSRF, and you cannot protect against it with anti-CSRF measures. If the user enters the login credentials to your site on an untrustworthy site, that's either a case of insanity or phishing. Either way, it's not CSRF, because the purpose of this attack would to grab the user credentials, not to have the user send those credentials to the target website. In fact, you'll probably wanna send the credentials yourself so that you yourself are logged in.

    Comments on this post

    • Northie disagrees : You should really learn to thoroughly read people's posts before flying off the handle at them
    Last edited by Jacques1; July 2nd, 2013 at 05:09 AM.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  6. #4
  7. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4123
    lets ignore phishing for a moment, I think it's confusing the discussion

    @Jacques1:

    Please re read my post:

    Originally Posted by Northie
    Depending on the nature of the form I could trick people into filling in the form when they didn't want to,
    (which Implies I'm talking about forms in general)

    and

    Originally Posted by Northie
    I don't know what the name for the latter type
    CRSF does not have to be targetted only on authenticated users; CRSF relies on a user's trust in the browser - a trust that is exploited in an attack.

    Why an attacher would target non authenticated users, I don't know - I'm not an attacker, but the method is the same and can be prevented against using anti-CSRF tokens

    I know exactly what CSRF is, and how to prevent it, It's not my problem if you can't understand what I'm writing.
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  8. #5
  9. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Originally Posted by Northie
    (which Implies I'm talking about forms in general)
    OK, let's say it's not the login form but instead a form which allows guests to submit comments. Now what exactly is the danger of unknown_guest_1 getting unknown_guest_2 to submit a comment -- as opposed to submitting it himself? Both have exactly the same privileges (none), and none of them carries any identity information. It's just one unknown sender replaced with another unknown sender.

    What you're basically trying to do is prevent cross-site requests as a whole. You sure can do that, but it has nothing to do with CSRF protection, and the question is: What's the purpose of this? Why are you doing it?



    Originally Posted by Northie
    CRSF does not have to be targetted only on authenticated users; CRSF relies on a user's trust in the browser - a trust that is exploited in an attack.
    Attack against whom, against what? CSRF has the word "forge" in it. You forge things that carry some kind of value. You don't forge things anybody can freely create at any time.



    Originally Posted by Northie
    Why an attacher would target non authenticated users, I don't know - I'm not an attacker, but the method is the same and can be prevented against using anti-CSRF tokens
    How do you wanna protect yourself against attacks when you don't even know the motivation behind them?

    Of course you can randomly fill your website with all kinds of security measures. But I doubt this will help you if you don't know why you're doing it and what you're trying to prevent.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".

IMN logo majestic logo threadwatch logo seochat tools logo