Thanks to all their replies!
But my point was not including ant random token in the url. If the url is something like this:
https://mysite.com/myportal/b1/04_SjzQ0NTYyNzS2MLTUj9CPykssy0xPLMnMz0vMAfGjzOJDfU19LNxMTQwsAoydDDyNXb0cnc2dDA2czfRzoxwVAVLe6h0!/

The above url keeps changing per user/ per session for all pages. Is that still at risk of CSRF?

Thanks & Regards,
Nilesh Kumar,
Security Analyst, Honeywell, Bangalore, India
http://nileshkumar83.blogspot.com

From: Michal Zalewski lcamtuf@coredump.cx
To: nilesh kumar nileshkumar83@yahoo.co.in
Sent: Thursday, 25 October 2012 10:08 PM
Subject: Re: [WEB SECURITY] URL Rewriting an effective measure against CSRF?

Oh, forgot another important point: they need to expire at some point.
Otherwise, a short-lived XSS that steals XSRF tokens could cause
long-term problems.

/mz

Hi,

It depends exactly how it's implemented. If that 04_Sjz... string is
generated from the page name, and the session ID, and in such a way that
a user cannot forge the number, then basically yes you are protected.

To give you more detailed advice, I'd have to do a full review of this
setup. You could contact our sales department if you're interested in that.

Paul

On 26/10/2012 11:39, 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 think one thing that hasn't been mentioned much is server side
checking of the tokens.

The client can send tokens anyway it pleases, some more secure than
others, but it is useless (if combined with other attacks) unless the
server checks the validity of those tokens. At least this is my
understanding of CSRF prevention and the OWASP CSRF Prevention Cheat
Sheet seems to agree (it could have been the original source of my
understanding of it).

On Fri, Oct 26, 2012 at 1:33 PM, Paul Johnston
paul.johnston@pentest.co.uk wrote:

Am 26.10.2012 12:39, schrieb nilesh kumar:

aah, looks like a WAF with URL encryption, good ;-)

as long as the application has no stored XSS, I'd consider: not vulnerable to CSRF

Keep other comments in mind about

• unique random token
• token per user and session
• token bound to user session and checked

Achim

Yes, to a certain extent URL rewriting (like the example provided by you) limits the scope of CSRF attack. The example URL appears to be not just simple URL rewriting but seems to have been modified to store a per-session, unique, and random value both in session state (most likely) and as part of the URL. However on the flipside it introduces other vulnerabilities since proxy logs and browser caches make the unique string available. You may like to double check whether the unique string in the URL is same as the session token. If so, then you may have to consider the issues introduced here i.e. those tokens in the URL will get cached in the proxy logs and browser cache.

One downside of this approach is that it impact the usability of the application i.e. bookmarking page other than the landing page becomes quite difficult. Therefore, if you expect users of the application to bookmark pages other than the home page, URL rewriting is probably not a good solution here. Another less talked area in URL rewriting is it’s overall impact on application performance. If it is extensively used and there are many users of the application at any given point then there is considerable amount of overall performance impact on application. However, this issue may be ignored if the number of users at any given point is less. The same applies when unique random tokens are used as a preventive measure against CSRF.

My preferred solution is to consider using the unique token based approach (only to be used where critical actions are performed) in conjunction with CAPTCHA or re-authentication. In other words, the tokens to be used only at those places in the application where critical actions are triggered. It will reduce the overall impact on application performance as the server side app does not have to deal with these tokens for all requests except for those critical requests. In addition, a CAPTCHA or a user re-authentication could be used for those super critical sections of the application as an additional layer of security. Unlike the standard all request token approach, this approach balance both security and performance.

The bottom line is any such defense mechanism is just that: defense-in-depth and limits the scope of attack to a maximum extent until proven wrong :D

-d

www.coffeeandsecurity.com

From: websecurity [mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of nilesh kumar
Sent: 26 October 2012 16:09
To: websecurity@webappsec.org
Subject: Re: [WEB SECURITY] URL Rewriting an effective measure against CSRF?

Thanks to all their replies!

But my point was not including ant random token in the url. If the url is something like this:

https://mysite.com/myportal/b1/04_SjzQ0NTYyNzS2MLTUj9CPykssy0xPLMnMz0vMAfGjzOJDfU19LNxMTQwsAoydDDyNXb0cnc2dDA2czfRzoxwVAVLe6h0!/

The above url keeps changing per user/ per session for all pages. Is that still at risk of CSRF?

Thanks & Regards,
Nilesh Kumar,
Security Analyst, Honeywell, Bangalore, India

http://nileshkumar83.blogspot.com

From: Michal Zalewski lcamtuf@coredump.cx
To: nilesh kumar nileshkumar83@yahoo.co.in
Sent: Thursday, 25 October 2012 10:08 PM
Subject: Re: [WEB SECURITY] URL Rewriting an effective measure against CSRF?

Oh, forgot another important point: they need to expire at some point.
Otherwise, a short-lived XSS that steals XSRF tokens could cause
long-term problems.

/mz