[WEB SECURITY] On Session Riding, Client-side Trojans and Cross-site Request Forgeries
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
> | 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
> shh at thathost.com My web security book: Innocent Code
> http://shh.thathost.com/ http://innocentcode.thathost.com/
Bill Pennington, CISSP, CCNA
WhiteHat Security Inc.
The Web Security Mailing List
More information about the websecurity