[WEB SECURITY] On Session Riding, Client-side Trojans and Cross-site Request Forgeries

Bill Pennington bill at whitehatsec.com
Wed May 4 12:29:58 EDT 2005

Sure Sverre I will break down the examples you give in 

http://www.example.com/vote.asp?alt=2 casting a vote for item number 2. 
To me this is clearly insufficient authorization. A snippet for the 
WASC Threat Classification.

"Insufficient Authorization is when a web site permits access to 
sensitive content or functionality that should require increased access 
control restrictions."

There is a lot of wiggle room there but I think we can say allowing 
people to vote directly (clicking on a link, posting a form from 
offsite) is access to sensitive functionality and it requires a bit 
more authorization (at least a referrer check would be nice)

Going further into the example you are using various "tricks" to get 
the user to go there. This is where the social engineering comes into 
play but the root cause is still the same, the vote.asp needs more 

The forum posting example is HTML Injection, the email is social 
engineering combined with what I would call an e-mail client exploit, 
others would call it a client feature :-) Still the problem stays the 
same, not enough authorization on the target app. I think this is 
confirmed but the solution you propose. The ticket is a form of 
authorization you are putting into the request.

I see it like it is a buffer overflow and all the ways you get someone 
to "exploit" it are offsets for the different platforms. Perhaps that 
is a bad analogy but that is what my twisted little brain comes up 

On May 3, 2005, at 11:42 PM, Sverre H. Huseby wrote:

> Hi, Bill!
> Thanks for the kind words embedded in your reply!
> |   I am having a problem giving this a new name,
> I'm not suggesting we find a new name, I'm just pointing out that this
> is an issue that people tend to rediscover every now and then.
> |   it all looks like cross site scripting and/or Insufficient
> |   Authentication to me.
> It works on servers which are not vulnerable to HTML Injection, so
> it's not XSS in the traditional meaning of the word.  In fact,
> scripting need not even be involved.
> |   I think we should try to be rather ruthless in giving things new
> |   names when they are just combinations or variations of an existing
> |   threats.
> Agreed.
> As I see it, the existing threat is Social Engineering.  You trick
> people into doing something they don't see the consequences of.
> |   In your examples from the webappsec posting I would infer that a
> |   session does not even exist for the voting app so how can I be
> |   riding one?
> Exactly.  That's why I still call it "Web Trojans" myself. :)
> |   I hope you don't take my rant as an attack to what you have put
> |   together
> Not at all, Bill!
> |   I see these types of problems everyday and I think they fit well
> |   into the existing classification system [...]
> That's what I fail to see.  It's not XSS, it may have something to do
> with authentication, and it has something to do with Social
> Engineering.
> If your time permits, would you please tell me how you would describe
> it using the existing classification system?
> Sverre.
> -- 
> shh at thathost.com               My web security book: Innocent Code
> http://shh.thathost.com/       http://innocentcode.thathost.com/
> ---------------------------------------------------------------------
> The Web Security Mailing List
> http://www.webappsec.org/lists/websecurity/

Bill Pennington, CISSP, CCNA
VP Services
WhiteHat Security Inc.

The Web Security Mailing List

More information about the websecurity mailing list