in reply to Re^6: Perl Sessions and Cookies - Cookie don't get passed
in thread Perl Sessions and Cookies - Cookie don't get passed

Q: My web site login/logout code needs to delete cookies, how can I do this?

A: You don't do login/logout that way, it's not standard practice and what you are trying to do screams XSS attack.

Instead of deleting a cookie don't send your anti XSS hidden input.

All web forms should have some post/get variable with a secret code that only that user knows. This ensures that forms, without having the correct hidden input value, can't be submitted to the site. The site code can easily determine if the form being filled out originated from the site.

  • Comment on Re^7: Perl Sessions and Cookies - Cookie don't get passed

Replies are listed 'Best First'.
Re^8: Perl Sessions and Cookies - Cookie don't get passed
by Anonymous Monk on Mar 08, 2015 at 14:01 UTC
    anti XSS hidden input

    I am still confused about this, but I realized maybe it's just a miscommunication - maybe we're talking about a different attack? What's your definition of an XSS attack?

    If you really do mean a Cross-site scripting attack, I'd love to see an example of how a hidden input prevents it?

[reply]

      Webserver A presents the use with a form with post or get url located on a website it does not host.

      The user fills in the form and submits it. Webserver B get's a request out of the blue for a URL that a Site B provided by Webserver B uses as a post or get url.

      However the form given by Site B is different than the one given to the user by Webserver A. The code for Site B running on Webserver B checks the user's credentials. If not done correctly the form submission may pass allowing any content to be submitted by OPs on any other Webserver on the Internet, plus "file://" too.

      The Nasty bit is that the Form from Webserver A can look like your typical user registration page, username and double password entries... Plus some hidden inputs the OP of Webserver A would like users to post to Webserver B, like a advertisement meant to be tweeted. If the user enters the same User/Password as they do for Twitter, then the OPs message will be tweeted... Accepting this Twitter is not so easily fooled.

      Target Vector:
      Site Cookies for auth. Cookies are passed to Site B, regardless of referral, at least they used to be.

      Prevention:
      Form generation includes a hidden input who's value the attacking OP would not know. Absence of this variable in any form submission can be denied.

      This technique is so standard that there is a proper name given to a hidden input used in this manner and if memory serves even a TLA. Though I can't be expected to know everything.

[reply]

        Ok, but that's not an XSS attack, at least I don't see any mention of client-side script code injection. What you're describing sounds kind of like a CSRF attack, which can be prevented via hidden form inputs. (I would have hoped that you would have read Cross-site scripting by now, considering you're the one who linked to it four days ago.)

[reply]

In Section Seekers of Perl Wisdom