This flaw exists in most authentication systems I see, but I've had trouble convincing people (including myself) that it's really a problem. The attack can be just a CSRF which submits the attackers credentials to log in the victim and then redirects them to the site. Many to most authentication schemes don't have nonces in the login form. What attacks does this allow? I see a few: 1. Getting someone to enter info that only they know (data extraction). This could involve passwords, CC numbers, SSNs, Intellectual Property, and pretty much any other data or actions involved in the application. 2. Framing someone for hacking. 3. Taking advantage of someone else's hard work (taking surveys, entering raffles, etc). I know that there is a big issue with the victim noticing that the system is treating them like a different user, but's lets ignore that. What do your devious minds see? http://sla.ckers.org/forum/read.php?4,34472,34472#msg-34472 Wed, 19 Jun 2013 07:12:25 -0500 Phorum 5.2.15a http://sla.ckers.org/forum/read.php?4,34472,34481#msg-34481 http://sla.ckers.org/forum/read.php?4,34472,34481#msg-34481
If not, then CryingWolf isn't just crying wolf. ;)]]> clayfox CSRF and Session Info Fri, 14 May 2010 09:26:10 -0500 http://sla.ckers.org/forum/read.php?4,34472,34480#msg-34480 http://sla.ckers.org/forum/read.php?4,34472,34480#msg-34480
Otherwise aren't the requests just from your account? Maybe it's a throwaway account and the goal is to distribute the requests among victim machines?]]> CryingWolf CSRF and Session Info Fri, 14 May 2010 08:54:18 -0500 http://sla.ckers.org/forum/read.php?4,34472,34475#msg-34475 http://sla.ckers.org/forum/read.php?4,34472,34475#msg-34475
Flash attacks- when the target site's crossdomain.xml file allows *.targetsite.com, and there's a flash upload vulnerability on bugs.targetsite.com, but exploiting it requires the user be logged into the attacker's profile, you:
a) log the user into your account
b) grab the flash payload
c) perform requests to www.targetsite.com

It sounds awfully specific, I know, but it's a wicked combo move, and far more common than I expected.

Similarly, there's a handful of other cross-subdomain attacks dealing with cookies. An XSS hole in a secondary app that's only accessible to the attacker can be used to poison/manipulate existing sessions of users in the main app without logging them out.

Another though, related to your data extraction- if you can, say, log somebody into your Google or Bing account, you can log in later and view any searches that they've made (opt-in on Google). Google added CSRF tokens to logins last fall, but those, too, can be bypassed with an XSS anywhere on *.google.com. (Not exactly easy these days, but it happens every once in a while)]]> mckt_ CSRF and Session Info Thu, 13 May 2010 22:51:01 -0500 http://sla.ckers.org/forum/read.php?4,34472,34472#msg-34472 http://sla.ckers.org/forum/read.php?4,34472,34472#msg-34472
The attack can be just a CSRF which submits the attackers credentials to log in the victim and then redirects them to the site. Many to most authentication schemes don't have nonces in the login form.

What attacks does this allow? I see a few:
1. Getting someone to enter info that only they know (data extraction). This could involve passwords, CC numbers, SSNs, Intellectual Property, and pretty much any other data or actions involved in the application.
2. Framing someone for hacking.
3. Taking advantage of someone else's hard work (taking surveys, entering raffles, etc).


I know that there is a big issue with the victim noticing that the system is treating them like a different user, but's lets ignore that.

What do your devious minds see?]]> clayfox CSRF and Session Info Thu, 13 May 2010 11:27:43 -0500