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

Sverre H. Huseby shh at thathost.com
Wed May 4 15:12:03 EDT 2005


[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.

|   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).

|   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.

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.


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/



More information about the websecurity mailing list