Suggested Checks: Cookies

[ChrisJohnRiley]

Arachni doesn't seem to alert on the following vulnerabilties .:

• Session Fixation

Note: The Proxy picks up 4 Cookie when you first visit Login.php (prior to login --> DVWA testbed), and after logon it doesn't pick up any further Cookies. I checked and the app doesn't alter the cookie after login. Not sure if Arachni checks for this logic, but it's a session fixation issue (cookie value not altered after logon).

• Cookies without HTTPOnly set (probably also Secure Flag --> untested)

[Zapotek]

Session fixation

It's kind of hard to determine if the session ID changes after a log-in because there's no way to know when the log-in happens -- especially when using the Proxy. I guess I could look for submitted forms containing a "type=password" field but then there's the issue of not knowing if the login was actually successful.

Plus, it may be bad practise not to update the Session ID after a log-in but it doesn't actually constitute fixation.

As the situation stands right now the best thing one can do to determine session fixation is check the results of the Profiler. If a taint has landed in the value of the session id cookie then there you go.

I suppose I can add a check specifically looking for taints that have landed in session cookies and log the issue.

(I've actually rewritten this reply 3 or so times, each with a different idea but this is the less complex and most elegant of all.)

If you've got any feedback for me let me have it.

HTTPOnly cookies/Secure flag

Simple enough, will add them in a jiffy. :)

[Zapotek]

For a second there I thought that I figured out a way to identify (server-side) session cookies programatically but nope. So I'll have to maintain a DB of known session ID cookie names which I don't really like but seems necessary.

[ChrisJohnRiley]

Yeah I understand it's not an easy problem.... a few random thoughts that might be worth discussion.

• How often and at what location to web apps set a cookie?
• If a cookie is set when first accessing the site and a form is loaded + submitted, can we say with a 90% certainty this was a login event?
• If a cookie is set and later on in a session a form is submitted with "user", "username", "uname", "password", "pword", "pass", ... as a field can we say with 75% certainty this was a login event?
• Can we apply the detection logic to the AutoLogin plugin, as the user will be providing the page for Login and therefore we can be (almost) 100% sure that this is indeed, the Login page. Alternative... a new plugin that is auto-enabled when AutoLogin is used, or can be manually enabled and provide the page or iFrame that handles the login process.

Just some thoughts on the issue. I think it's less about the cookie name and more about detecting the logic behind the login process by detecting the form submit.

Thoughts?

[Zapotek]

1. Any time and any place
2. I seriously doubt it -- biggest antagonist to this would be a search form
3. I'd say more than 75%, plus, like I mentioned, the existence of a password type input in the form can be a dead giveaway
4. Yes sure

And that's all good if only 1 cookie is involved in these procedures but the chances of that being true are so small nowadays that it'll pretty much render this useless.

The Proxy will be updated with an option to record a log-in operation in order to support detection of log-outs and automated re-logins. You know, inject a minimal UI in the responses to let the user record macro-like procedures so the login action can be guaranteed to be known.

But we still have to identify the right cookie... I could do something similar to what the CSRF module does but in a smarter fashion:

• sequentially nil out cookies for each request and record the responses
• request a page that we know what it looks like with valid cookies by deducing the login action like we've discussed
• compare the responses from the previous steps and see if we can find 2 that match, that would mean we've identified the right cookie

Or better yet, do the sequential thing for step 2 too just to be sure that we aren't working with noise created by another cookie that can somehow affect presentation.

That'd be a fun little exercise, heh. :)

[ChrisJohnRiley]

Love the idea of the proxy plugin having a little control panel... sounds like fun ;)

I like the idea of sequentially going through the cookies and requesting without it present to see the result. The only problem I can see if really badly coded web apps that have direct object reference issues (request without the cookie and you still get the same response), that and how to tell if a logon failed (and therefore the cookies are most probably useless anyway as they don't represent a valid session).

That does raise an interesting possibility though. Enable direct object reference checks by checking each page with and without the set cookies to compare results. I know Burp does offer something like that now.

[Zapotek]

I hadn't thought of adding a Direct Object Reference module (will do now) but I do the same thing to identify CSRF vulnerable forms that are important enough to log[1].

And as for DOR being a problem, I doubt that it'd be a problem for the page that facilitates or comes right after the login -- or we can take both into consideration.

We'd still be playing with the odds but hell if even that doesn't work I'm stumped (for now). I mean there's only so much you can do to compensate for a badly written webapp.

[1] http://trainofthought.segfault.gr/2010/10/11/paper-automated-detection-of-csrf-worthy-html-forms-through-4-pass-reverse-diff-analysis/

[ChrisJohnRiley]

Yeah, you can't cater for every application. Automated scans will always be something that needs a human to read and make sense of. Logically it's better to have the option as a module and let users exclude it if the app is so buggy that it has too many false positives.

[ChrisJohnRiley]

Re [1]: "See, I wanted to avoid noise in the scan report, nobody cares that a search form is vulnerable to CSRF." I beg to differ... you'd hate for me to poison your Google ad words search results by searching for the top 1000 pron words on Google I'm sure ;)

Just saying ;)

[Zapotek]

1. Well, that'd actually be useful if it happened because a bit of meta-analysis would be enough to flag it as untrusted (as it'd be way over a reasonable baseline). But, alas, I don't think that this module would trigger that.
2. True, although to be fair that's Google's problem -- way past the scope of web app sec regarding the target.

[ChrisJohnRiley]

Yeah, fun, but not really THAT interesting!

[Zapotek]

Time to work on this.

I just added some new capabilities to the framework and the login plugins (well, just autologin atm) which will certainly help with this.

• The Framework class now accepts login_sequenceand login_check blocks to be used to detect logouts and re-login between auditing pages.
• The autologin plugin now:
  • has a login_verifier option as a regexp to check whether or not the login was successful;
  • configures the Framework with the previous blocks upon successful logins.

And the same thing will go for the new proxy plugin as well (which I'll start developing tomorrow probably).

There still is the issue of DOR but there's only so much we can do.