Hi,

Unless you're checking the unique URL server side on the submission of
the form/URL I don't think it will be effective.

If combined with XSS, the unique (re-written) target URL could be
known by an attacker before the submission.

The re-written URL would also have to be unpredictable.

My 2pence.

Ryan

On Thu, Oct 25, 2012 at 4:57 PM, nilesh kumar nileshkumar83@yahoo.co.in wrote:

Hi Nilesh,

I take it you mean including a random token within each URL, perhaps
something like:

/myapp/save_data?token=x129e3nd3

Provided that the token is unpredictable, and is correctly validated on
all applicable pages, this is sufficient to stop CSRF. It is essentially
the same method as putting a token in a hidden form field - it's just in
the URL instead.

However, it's not a scheme you often see in practice, for several reasons:

1. It's quite difficult to implement this. In many applications you'd
   have to edit every template the includes a URL. One possible way to
   avoid this is to include the token in the path segment (e.g.
   /myapp/x123098d/save_data) - but not something I see in practice.

2. It stops users bookmarking pages, or emailing URLs to other users. If
   the token changes with each request, it also stops them using the back
   button. I think this is the main reason that this pattern isn't seen
   much in practice.

3. The URL is generally considered a poor place to store sensitive data
   as it can leak, e.g. to other servers in the referer header. Not the end
   of the world for an anti-xsrf token, but not ideal.

Putting the token in a hidden field largely solves these concerns, so
it's the common pattern.

Paul

On 25/10/2012 15:57, nilesh kumar wrote:

--
Pentest - When a tick in the box is not enough

Paul Johnston - IT Security Consultant / Tiger SST
Pentest Limited - ISO 9001 (cert 107029) / ISO 27001 (cert 558982)

Office: +44 (0) 161 233 0100
Mobile: +44 (0) 7817 219 072

Email policy: http://www.pentest.co.uk/legal.shtml#emailpolicy
Registered Number: 4217114 England & Wales
Registered Office: 26a The Downs, Altrincham, Cheshire, WA14 2PU, UK

I'm also a bit wondering about what you mean by "URL rewriting".
If you mean something like
/some/thing;token=random
or
/some/thing?token=random

in addition to your session ID (i.e. in the cookie), then this could be a
countermeasuer against CSRF as long as:
- the token is random and not guessable
- the application has no stored XSS

Most people will argue that any secret value (like session IDs or tokens) in the
URL must be avoided 'cause

• it will be logged in the server
  if an attacker gains access to that logs, you most likely have much more
  problems to solve than mitigating CSRF
• it will be send in refere header
  a secure application has no links to external servers, this can be
  controlled by the application itself
• the URL can be "seen" by the attacker (photo and such), aka shoulder surfing
  I'd say that this is a bit unlikely today, at least low risk
• the URL can be copied by the user and send elswhere
  well, this is a true risk, but the user needs to do it
  your application can help here, if the token is useless without a valid
  session ID, i.e. in a cookie

I disagree with other comments, that implementing an additional token in the URL
is difficult. Tis can be done by an application container. There also exists a
couple of WAFs which do exactly that. It's transparent to any application, even
legacy ones.

If bookmarking an URL for a secure application is more relevant than the security
of the application, something went wrong somewhere else, IMHO. Think secure!

If you mean that your "URL rewriting" is just another mode instead using cookies
like:
/some/thing;*sessionid=random

then the countermeasuer is less useful.

Hope this helps
Achim

Am 25.10.2012 16:57, schrieb nilesh kumar:

I'd also add to this list that it may be

• cached in the browser. Mind you you'd likely need another exploit/abuse
  to obtain it, but still worth mentioning.
• cached in proxy logs (when an explicit or transparent proxy is in use)

The above items do not factor in when SSL is/isn't used and is
general observations.

Regards,

• Robert A
  http://twitter.com/robertauger
  http://www.webappsec.org
  http://www.cgisecurity.com/
  http://www.qasec.com/

oops, I presumed that SSL is in use for secure applications ;-)

If proxy logs count, it's the same as for server logs: much bigger problem if an
attacker can gain access.
Browser cache may count if there are other exploits available. But then the client
is already compromised, why should an attacker then make use of CSRF?
I'm open for discussions here ...

Achim

Am 25.10.2012 18:28, schrieb Robert A.:

Hi,

Perhaps for a highly sensitive site like online banking this is true.

But there are many sites which are less sensitive, but stopping CSRF is
important. Take Facebook as an example. Clearly stopping CSRF is
important - can you imagine all the unwanted "likes" and malicious
status updates if it was possible? However, it's also critical that
users can emails URLs to each other, e.g. "hey look at this page, you
can 'like' it too". And there's no great problem for them - you don't
need dynamic data in URLs to be secure.

Paul

--
Pentest - When a tick in the box is not enough

Paul Johnston - IT Security Consultant / Tiger SST
Pentest Limited - ISO 9001 (cert 107029) / ISO 27001 (cert 558982)

Office: +44 (0) 161 233 0100
Mobile: +44 (0) 7817 219 072

Email policy: http://www.pentest.co.uk/legal.shtml#emailpolicy
Registered Number: 4217114 England & Wales
Registered Office: 26a The Downs, Altrincham, Cheshire, WA14 2PU, UK