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

Bill Pennington bill at whitehatsec.com
Wed May 4 15:43:39 EDT 2005

On May 4, 2005, at 12:12 PM, Sverre H. Huseby wrote:

> [Bill Pennington]
> |   http://www.example.com/vote.asp?alt=2 casting a vote for item
> |   number 2.  To me this is clearly insufficient authorization.
> I agree for this example, but it's just a "warm-up" to show the
> principles.
> |   The forum posting example is HTML Injection,
> No.  If I tell you to "take a look at http://badguy.org", it's no HTML
> involved, just human readable text.  Social Engineering again.

I was specifically referring to the forum post you mention right after 
the e-mail explanation. The way I read it is that forum is on the site 
you are attacking. It really does not matter if it is or is not the 
basic vulnerability is the same no matter what it is combined with.

> |   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.
> What is "not enough authorization"?  The user will log in as he always
> does.  Then his browser will post a request to transfer money, like he
> always does.  The only difference is that the request is initiated
> from the attacker's form rather than the bank's form.
> You can say that the user should not be authorized to post a request
> unless it originated from a bank web site.  In that case I agree that
> the authorization is insufficient.  But this insufficient
> authorization is, to some extent, present in all web applications I've
> seen so far, probably because developers associate authorization with
> access to resources, rather than with how a request is being made (my
> personal theory, just thought up).

Just because it is everywhere does not mean it is not horribly broken 
:-) Developers do look at these things the "wrong" way all the time. If 
I tell someone to not trust user input they will go make sure all of 
there form fields are validated and completely ignore URL parameters, 
cookies, hidden form fields etc... It boils down to a education and 
communication issue. One that I think the security community (including 
me) does not always do a good job with.

> |   I think this is confirmed but the solution you propose. The ticket
> |   is a form of authorization you are putting into the request.
> The goal of the tickets is to make the target web site able to figure
> out if the request originated with them, and not at some third pary.

...thus authorizing the request or providing sufficient authorization.

> I think I understand your point, and agree that this _may_ be seen as
> an authorization problem, albeit an unusual one requiring a solution
> not normally associated with authorization.  I do, however, think that
> it is sufficiently separate from other authorization problems that a
> separate name may be OK.  After all, we have both SQL Injection, LDAP
> Injection, HTML Injection, C Null-byte Injection and more, which are
> all just failure-to-deal-with-metacharacters problems.

For sure Insufficient Authorization is a big nasty bucket where a lot 
of stuff ends up in. I would not be opposed to breaking it into a few 
smaller chunks. I do want to avoid some problems I see in the OWASP top 
ten list where they list meta problems like input validation and then 
at the same level talk about sub-classes, like SQL injection. I think 
that causes a lot of confusion when you go try to implement a list like 

> Sverre.
> -- 
> shh at thathost.com               My web security book: Innocent Code
> http://shh.thathost.com/       http://innocentcode.thathost.com/

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

The Web Security Mailing List

More information about the websecurity mailing list