My Security Planet » Tags

19 items tagged "CSRF"

CGISecurity.com: Your Web Site and Application Security Resource

Improving ASP.NET Security with Visual Studio 2010 Code Analysis

Posted: December 6th, 2010, 2:58pm CST by Robert A.

Tags: CSRF [edit]

Sacha Faust has published a great article on some of the security checking functionality in Visual Studio. From the article "Anyone doing ASP.NET development probably admits, openly or not, to introducing or stumbling upon a security issue at some point during their career. Developers are often pressured to deliver code as quickly...

hackademix.net

X-Content-Type-Options, NoScript and Browserscope

Posted: October 29th, 2010, 8:45pm CDT by Giorgio

Tags: CSRF [edit]

NoScript 2.0.4 has been released yesterday, with some bug fixes and one main addition: strict X-Content-Type-Options: nosniff enforcement.

NoScript, for a long time, had already being enforcing content type checks on cross-site Javascript and CSS includes, and recent Firefox versions introduced similar built-in mitigations, albeit limited to stylesheets, in order to mitigate CSS-based data theft.

Nevertheless, X-Content-Type-Options offers a nice opportunity to further hardening, by allowing web sites to opt-in for the strictest checks, on more file types and also same-domain, in a theoretically compatible way.

A side effect of this addition is that Firefox 4 + NoScript now scores 14/16 on Browserscope’s Security Test, in “Allow Scripts Globally” mode (i.e., without blocking any JavaScript or active content)!

For those who don’t know it, Browserscope is a project which aims at profiling and comparing browser capabilities, with a special eye for security features.

By comparison, only Google Chrome boasts a higher score of 15/16, because it supports both the HTTP Origin Header and the HTML 5 Sandbox Attribute, which are not implemented yet by Firefox nor by NoScript. For the curious, “vanilla” Firefox 4 nightlies stop at 11/15 (even if you’re going to read 12/15 because of a XSS test bug), Firefox 3.6.12 + NoScript is at 13/15, while disabling NoScript makes it fall down to 9/16 (reported as 10/16 because of the aforementioned bug).

However, a fair comparison would need to cover also Content Security Policies, a very powerful and flexible security technology developed by Mozilla (test should be added soon, it seems) and countermeasures for cross-zone CSRF attacks (e.g. against routers), which are currently provided by NoScript and, partially, by Opera (Mozilla is working on something, too)*. If and when these features get tested, Firefox 4 + NoScript will lead at 16/18, followed by Chrome at 15/18.

That said, I’d really love to see Origin and Sandbox implemented natively by Firefox, for a perfect 18/18. Which is, I guess, the real raison d’être of Browserscope: getting good stuff implemented everywhere by the power of childish envy ;)

* I won’t advocate including tests for other non-blocking security features provided by NoScript, such as ClearClick anti-Clickjacking, because they’re not suitable for web-based automation.
Update 2010-11-13
Firefox 4 + NoScript scores 15/17 now!
al_9x Was Right, My Router is Safe

Posted: August 1st, 2010, 3:53pm CDT by Giorgio

Tags: CSRF [edit]
Senior NoScript community contributor Grumpy Old Lady finally sent me a link to these notes, taken live at BlackHat USA during Graig Heffner’s “How to Hack Millions of Routers” talk, and to the tool he released, allowing to remotely control the many models of routers found vulnerable to a specific kind of DNS Rebinding attack.

Since I couldn’t attend the L.A. conference, I’ve been anxiously in search of something like that to confirm al_9x’s speculative forecast, i.e. that the exploited vulnerability was about routers exposing their administrative interface to the LAN on their WAN IP (even if remote administration is explicitly disabled), and now I’m delighted to find he was entirely correct!

Of course I must be happy, because I don’t need to rush out another ABE feature like the WAN IP protection which I baked inside NoScript 2.0 last week, and because my own home router had been vulnerable as well :)

Some clarifications are still needed, though.

Among the mitigations reportedly enumerated by Heffner (even if he had previously claimed that NoScript couldn’t help), there’s

Use NoScript (disable javascript?) Maybe not practical to most users

Now, it is true that Heffner’s attack fails if the attacker’s domain, bound on the fly to user’s WAN IP, is not allowed to run JavaScript (very likely, when you use NoScript). This means that most users of older NoScript versions (1.10 and below) were already protected against Heffner’s tool and this kind of “XSS via DNS Rebinding”.

However, like for many other “emerging threats”, NoScript provides a specific protection against this class of vulnerabilities (in this case via its ABE module), completely independent from script blocking: in other words, it just works, no matter if you decide to keep JavaScript, plugins and frames enabled everywhere (”Allow Scripts Globally“). There’no reasonable excuse to renounce this protection, since it does not imply the alleged “non-practicality” of enabling JavaScript selectively.

So, since security experts themselves sometimes seem confused about NoScript’s real “convenience vs security” tradeoffs, taking for granted that all the security it offers depends on and requires script blocking, recapping here a (non exhaustive) list of attacks blocked by NoScript even in “Allow Scripts Globally” mode may be useful:
1. XSS, thanks to its “Injection Checker”, the first anti-XSS filter ever released in a web browser.
2. Clickjacking — NoScript’s ClearClick feature is still the only effective protection entirely implemented inside the browser and requiring no server-side cooperation.
3. CSRF (and especially, by default, cross-zone attacks against intranet resources) via the ABE module.
4. MITM, courtesy of HSTS and other HTTPS-enhancing features
These are just some of the many additional protections provided by NoScript which do not depend on scripting being disabled. So next time you hear people saying “yes, browsing with NoScript is safer but having to pick trusted sites to run JavaScript is a pain“, point them to these good reasons for running NoScript, even if they give up the extra security provided by plain old script blocking.

CGISecurity.com: Your Web Site and Application Security Resource

Preventing Security Development Errors: Lessons Learned at Windows Live by Using ASP.NET MVC

Posted: December 3rd, 2009, 4:46pm CST by Robert A.

Tags: CSRF [edit]

Microsoft has published a paper on its ASP.NET MVC framework, how to use it, and how utilization of an SDL eliminates the potential to introduce vulnerabilities such as XSRF. From the paper "On the Microsoft platform, most Web applications are based on ASP.NET and the Microsoft®.NET Framework. ASP.NET MVC is a new...
Hacking Short CSRF Tokens using CSS History Hack

Posted: July 20th, 2009, 3:22pm CDT by Robert A.

Tags: CSRF [edit]

Securethoughts has posted an entry on combining CSS history theft hacking to brute force short CSRF tokens and has created a POC demonstrating it. While not fast this is certainly achievable (assuming the token is still valid/hasn't expired once identified) on short CSRF token values, and has the advantage in that...
Amazon CSRF "hack" in detail?

Posted: April 19th, 2009, 10:17pm CDT by Robert A.

Tags: CSRF [edit]

UPDATE: According to an updated Wired news story this is a sham and no hacker was involved. RSnake recently posted an entry linking to the write up on how a Cross-Site Request Forgery flaw in amazon was used to get Gay and Lesbian books banned from amazon's site via their reputation...
New Gmail Flaw Lets Attacker Control 'Change Password' Function

Posted: March 3rd, 2009, 4:34pm CST by Robert A.

Tags: CSRF [edit]

"A researcher today released a proof-of-concept for a vulnerability he discovered in Google Gmail that lets an attacker change a Gmail user's password, wage a denial-of-service attack on the account, or even access other Gmail users' email. The cross-site request forgery (CSRF) flaw -- which researcher Vicente Aguilera Diaz from Madrid-based...
Protect Your Site With URL Rewriting

Posted: February 23rd, 2009, 3:10pm CST by Robert A.

Tags: CSRF [edit]

Bryan Sullivan over at Microsoft has published a lengthy article on the advantages of URL writing to prevent certain types of attacks. "Tim Berners-Lee once famously wrote that "cool URIs don't change." His opinion was that broken hyperlinks erode user confidence in an application and that URIs should be designed in...
Web Application Scanners Comparison

Posted: January 27th, 2009, 11:30am CST by Robert A.

Tags: CSRF [edit]

anantasec posted a scanner comparison to the web security mailing list today. "In the past weeks, I've performed an evaluation/comparison of threepopular web vulnerability scanners.This evaluation was ordered by apenetration testing company that will remain anonymous. The vendorswere not contacted during or after the evaluation.The applications (web scanners) included in this...

hackademix.net

Introducing ABE

Posted: December 19th, 2008, 6:27pm CST by Giorgio

Tags: CSRF [edit]
During the past weeks I’ve started a new project called ABE, sponsored by the NLnet Foundation and meant to provide CSRF countermeasures configurable on the client side, the server side or both.

As you probably know, the NoScript browser extension improves web client security by applying a Default Deny policy to JavaScript, Java, Flash and other active content and providing users with an one-click interface to easily whitelist sites they trust for active content execution. It also implements the most effective Cross-Site Scripting (XSS) filters available on the client side, covering Type-0 and Type-1 XSS attacks; ClearClick, the only specific browser countermeasure currently available against ClickJacking/UI redressing attacks, and many other security enhancements, including a limited form of protection against Cross-Site Request Forgery (CSRF) attacks: POST requests from non-whitelisted (unknown or untrusted) sites are stripped out of their payload and turned into idempotent GET requests.

Many of the threats NoScript is currently capable of handling, such as XSS, CSRF or ClickJacking, have one common evil root: lack of proper isolation at the web application level. Since the web has not been originally conceived as an application platform, it misses some key features required for ensuring application security. Actually, it cannot even define what a “web application” is, or declare its boundaries especially if they span across multiple domains, a scenario becoming more common and common in these “mashups” and “social media” days.

The idea behind the Application Boundaries Enforcer (ABE) module is hardening the web application oriented protections already provided by NoScript, by developing a firewall-like component running inside the browser. It will be specialized in defining and guarding the boundaries of each sensitive web application relevant to the user (e.g. webmail, online banking and so on), according to policies defined either by the user himself, or by the web developer/administrator, or by a trusted 3^rd party.

ABE rules, whose syntax is defined in this specification (pdf), are quite simple and intuitive, especially if you ever looked at a firewall policy file:
```
# This one defines normal application behavior, allowing hyperlinking
# but not cross-site POST requests altering app status
# Additionally, pages can be embedded as subdocuments only by documents from
# the same domain (this prevents ClickJacking/UI redressing attacks)
Site *.somesite.com
Accept POST, SUB from SELF, https://secure.somesite.com
Accept GET
Deny

# This one guards logout, which is foolish enough to accept GET and
# therefore we need to guard against trivial CSRF (e.g. via <img>)
Site www.somesite.com/logout
Accept GET, POST from SELF
Deny

# This one guards the local network, like LocalRodeo
# LOCAL is a placeholder which matches all the LAN
# subnets (possibly configurable) and localhost
Site LOCAL
Accept from LOCAL
Deny

# This one strips off any authentication data
# (Auth and Cookie headers) from requests outside the
# application domains, like RequestRodeo
Site *.webapp.net
Accept ALL from *.webapp.net
Logout
```
Living inside the browser, the ABE component can take advantage of its privileged placement for enforcing web application boundaries, because it always knows the real origin of each HTTP request, rather than a possibly missing or forged (even for privacy reasons) HTTP Referer header, and can learn from user’s feedback.
Rules for the most popular web applications will be made downloadable and/or available via automatic updates for opt-in subscribers, and UI front-ends will be provided to edit them manually or through a transparent auto-learning process, while browsing. Additionally, web developers or administrator will be able to declare policies for their own web applications: ABE will honor them, unless they conflict with more restrictive user-defined rules.
As soon as browser support for the Origin HTTP header becomes widespread and reliable, an external version of ABE might be developed as a filtering proxy.

An initial implementation will be released during the 1^st quarter of 2009 as a NoScript module.
I already collected precious feedback from security researchers like Arshan “Anti-Samy” Dabirsiaghi, Ivan Ristic of ModSecurity fame, Sirdarckcat and others.
More opinions and suggestions about rules design and features are very welcome.

CGISecurity.com: Your Web Site and Application Security Resource

Researchers from Princeton University Publish vulnerabilities in unpatched sites

Posted: September 30th, 2008, 12:41pm CDT by Robert

Tags: CSRF [edit]

Yesterday a couple of 'researchers' published that a couple of major sites were vulnerable to CSRF. A general rule of thumb is that unless you are explicitly protecting against CSRF, or are accidentally protected, then you're vulnerable. CSRF in 2008 is what XSS was in 2002, somewhat understood and rarely protected...
Researchers from Princeton University Publish vulnerabilities in unpatched sites

Posted: September 30th, 2008, 12:41pm CDT by Robert

Tags: CSRF [edit]

Yesterday a couple of 'researchers' published that a couple of major sites were vulnerable to CSRF. A general rule of thumb is that unless you are explicitly protecting against CSRF, or are accidentally protected, then you're vulnerable. CSRF in 2008 is what XSS was in 2002, somewhat understood and rarely protected...
Checking for ViewStateUserKey using FxCop

Posted: September 26th, 2008, 5:41pm CDT by Robert

Tags: CSRF [edit]

An anonymous user writes "ASP.NET has had a mitigation to prevent against CSRF/One-Click attacks since 1.1 with the use of Page.ViewStateUserKey property. You can now make sure that the property is being used using FxCop." Link: https://blogs.msdn.com/sfaust/archive/2008/09/25/checking-for-viewstateuserkey-using-fxcop.aspx
ViewStateUserKey Doesn’t Prevent Cross-Site Request Forgery

Posted: September 18th, 2008, 11:29am CDT by Robert

Tags: CSRF [edit]

"ViewStateUserKey is not a completely effective mitigation against Cross-Site Request Forgery. It doesn't work for non post-backs (I.e. GET requests), and it doesn't work if the ViewState MAC is turned off. In several different places, we see a piece of advice repeated - use the ViewStateUserKey property to prevent One-Click Attacks....
ViewStateUserKey Doesn’t Prevent Cross-Site Request Forgery

Posted: September 18th, 2008, 11:29am CDT by Robert

Tags: CSRF [edit]

"ViewStateUserKey is not a completely effective mitigation against Cross-Site Request Forgery. It doesn't work for non post-backs (I.e. GET requests), and it doesn't work if the ViewState MAC is turned off. In several different places, we see a piece of advice repeated - use the ViewStateUserKey property to prevent One-Click Attacks....
WASC Announcement: 2007 Web Application Security Statistics Published

Posted: September 8th, 2008, 11:39am CDT by Robert

Tags: CSRF [edit]

The Web Application Security Consortium (WASC) is pleased to announce the WASC Web Application Security Statistics Project 2007. This initiative is a collaborative industry wide effort to pool together sanitized website vulnerability data and to gain a better understanding about the web application vulnerability landscape. We ascertain which classes of attacks...
Article: SDL Embraces The Web

Posted: September 2nd, 2008, 11:43am CDT by Robert

Tags: CSRF [edit]

Bryan Sullivan from Microsoft has posted an article on SDL use to secure web applications. "The Security Development Lifecycle (SDL) team recently released details of the SDL process that has been so successful in helping to make Microsoft products more secure. You can find these documents at microsoft.com/sdl. As you read...
Tools: Grendel Scanner a new Web Application Security Scanner

Posted: August 12th, 2008, 3:21pm CDT by Robert

Tags: CSRF [edit]

While attending defcon I got to check out a talk on a new web application security scanner called Grendel scanner. For those of you who don't know I used to work at spi dynamics on the webinspect product (now part of HP) and I got to say it is one of...

hackademix.net

Site Security Policy, AKA Content Restrictions

Posted: June 5th, 2008, 8:33am CDT by Giorgio

Tags: CSRF [edit]
A couple of months ago, Brandon Sterne of the Mozilla Security Team asked me some questions about NoScript’s internals, because he was developing a Firefox add-on which involved selective script-blocking.

Looks like he finally delivered: Site Security Policy is a proof of concept for an idea proposed by RSnake and turned into a specification by Gervase Markham, known as “Content Restrictions”.

A Site Security Policy is defined by the website administrator and communicated to the web browser as a set of special “X-SSP-…” HTTP headers either attached to the affected content or sent in response to a “discovery” HEAD request:
- X-SSP-Script-Source specifies a deny/allow list of hosts which are allowed to run scripts.
  If this header is sent, no embedded script is allowed to run, and only included scripts whose sources match the rules are executed. This is an effective anti-XSS countermeasure, and could be extremely useful for so called “Web 2.0″ sites featuring user-generated rich content.
- X-SSP-Request-Source lists the hosts which can or cannot send HTTP requests to a certain resource, and the “acceptable” HTTP verbs.
  This can help enforcing referrer-based checks against CSRF attacks which work even if user chooses to omit or spoof the Referer header for privacy reasons, and mitigating verb-tampering attacks when used to “enhance” CSRF.
- X-SSP-Request-Target limits the destinations of requests originated by the current page.
  This may help mitigating data-leakage outcomes of a successful XSS attack, e.g. by preventing authentication tokens from being logged to remote hosts, but also avoiding the page to be used as a platform for CSRF attacks and blocking inclusion of unwanted 3rd party content.
- X-SSP-Report-URI declares an URL where policy violation attempts should be logged by the browser.
If you want to start applying these restrictions to your web content, you’ll find a detailed yet simple reference with examples on Brandon’s project web site.
Implementing a Site Security Policy cannot surrogate web developers’ security awareness and best practices, but it’s nonetheless a big step forward in making a website safer for its users.

Obviously enough, to be generally effective this technology still needs to be evangelized to administrators and coders, correctly deployed and supported in a consistent cross-browser fashion. But as soon as it gets built in our favourite browser and we begin to see badges like “Browsing this site is safer with Firefox”, we can hope other vendors to join making the Web a safer place.

My Security Planet » Tags » CSRF

Feeds

19 items tagged "CSRF"

Posted: December 6th, 2010, 2:58pm CST by Robert A.

Tags: CSRF [edit]

Posted: October 29th, 2010, 8:45pm CDT by Giorgio

Tags: CSRF [edit]

Posted: August 1st, 2010, 3:53pm CDT by Giorgio

Tags: CSRF [edit]

Posted: December 3rd, 2009, 4:46pm CST by Robert A.

Tags: CSRF [edit]

Posted: July 20th, 2009, 3:22pm CDT by Robert A.

Tags: CSRF [edit]

Posted: April 19th, 2009, 10:17pm CDT by Robert A.

Tags: CSRF [edit]

Posted: March 3rd, 2009, 4:34pm CST by Robert A.

Tags: CSRF [edit]

Posted: February 23rd, 2009, 3:10pm CST by Robert A.

Tags: CSRF [edit]

Posted: January 27th, 2009, 11:30am CST by Robert A.

Tags: CSRF [edit]

Posted: December 19th, 2008, 6:27pm CST by Giorgio

Tags: CSRF [edit]

Posted: September 30th, 2008, 12:41pm CDT by Robert

Tags: CSRF [edit]

Posted: September 30th, 2008, 12:41pm CDT by Robert

Tags: CSRF [edit]

Posted: September 26th, 2008, 5:41pm CDT by Robert

Tags: CSRF [edit]

Posted: September 18th, 2008, 11:29am CDT by Robert

Tags: CSRF [edit]

Posted: September 18th, 2008, 11:29am CDT by Robert

Tags: CSRF [edit]

Posted: September 8th, 2008, 11:39am CDT by Robert

Tags: CSRF [edit]

Posted: September 2nd, 2008, 11:43am CDT by Robert

Tags: CSRF [edit]

Posted: August 12th, 2008, 3:21pm CDT by Robert

Tags: CSRF [edit]

Posted: June 5th, 2008, 8:33am CDT by Giorgio

Tags: CSRF [edit]