Tag Archives: xss

Dude, where’s my WordPress session?

WordPress is a favourite hackers target. Some say that is because it is inherently insecure, but in reality WordPress is mainly a target because of its popularity, because of people not keeping their installations up to date or using easy to guess usernames and passwords and because of vulnerabilities in plugins rather then WordPress itself.

There is, however, one security-related shortcoming in WordPress from a design point of view: sessions are not stored server-side. If someone logs in, a cookie is set in the browser containing username, a session expiration timestamp and a hash. With every new request to WordPress that cookie (and specifically the hash) is checked to validate the session, but there is no check to see if there indeed was such a session.

This can be considered mainly a theoretical shortcoming, not an immediately exploitable vulnerability, because;

  1. session-cookies are set with the HTTPOnly-flag so XSS should not be an issue
  2. in an ideal world all traffic, once logged in, would be over HTTPS, securing against network sniffing.

But there are other (albeit less obvious) ways to steal cookies or even create create new ones to gain unauthorized access, as demonstrated in this very detailed blogpost. As explained in that article, there is no way to block “fake” session-cookies from gaining access (your OTP plugin won’t protect you either) and there is no functionality to monitor and if needed delete sessions.

So … I wrote a small proof-of-concept plugin that gets triggered upon login, logout and upon session verification (i.e. each request) and which stores sessions server-side, automatically logging out unknown sessions. With that in place, lots of other optional features could easily be added;

  • display a list of all known current sessions
  • allow one or more sessions to be removed
  • compare IP address at session verification against the one at session creation and notify or logout if no match
  • compare User Agent (and optionally some HTTP accept-headers) at session verification against the one at session creation and notify or logout if no match
  • create an audit log

But … I don’t want to do this on my own. I have 3 plugins already, 2 of which are semi-popular and for which I try to do regular releases and provide great support (and I have a daytime-job and a wife and daughter with whom I love to spend quality time as well). Moreover I really don’t want the plugin to “just” be open source, but I want it to be developed in an open source, collaborative manner as well.

So if you’re a WordPress coder, a security consultant or just an innocent passer-by and you are willing to code, review code, translate or document, then do drop me a line. Fame (but not fortune) will be yours!

Web API security basics

When I proposed the lead developer of an open source web application to enable JSONP for the API, the developer replied:

The whole thing sounds easy enough to implement, but I have some doubts that it will open the project to XSS attack of some sort. Don’t really know why, though. :-)

We mailed a bit more about the risks of cross site scripting and then he wrote the following:

Sadly we can have malicious JS problems since cleaning up of incoming data is optional.

For an unrelated project I asked about authentication for a write-operation in the API and the reply was:

Authentication is not in the API yet. Currently you must include a session cookie along with API requests to perform a write, but the cookie itself is the one you get from logging in [in the web front end] as you would normally.

Which sounds a lot like “we support cross site request forgery out of the box” …

As with normal web applications, web API-security is an important (but complex) issue, which is not always easy to grasp. Based on a basic understanding of things, the following guidelines can go a long way into securing things both on the API-side and the client:

  1. Know who you’re dealing with; disable API-access for your users by default (allowing them to opt-in), provide bullet-proof authentication and session management in the API and throw in a synchronizer token to prevent cross site request forgery
  2. Never trust input from users or external systems; decide what to trust and filter out everything that’s not in that white-list (SQL-code, server-side code, javascript, and even html and css)

If you apply these basic principles to JSONP (make sure to filter the callback-parameter and set the correct content-type in your response) you’ll have a whole lot less to worry about!

More info:

Browser enforced web application security; IE8 safest?

microsoft internet explorer 8 logoWith a notoriously bad reputation for security (or the lack thereof) in Internet Explorer, Microsoft claims to have invested a lot in IE8 security in general and specifically in browser enforced website security. Indeed, according to the product site, IE8:

[…] helps protect you from today’s threats, including malware and phishing, as well as emerging threats that can compromise your computer without your knowledge. Other browsers either don’t offer you this level of protection or require you to download and configure third-party add-ons to get it, but with Internet Explorer 8 you get it right out of the box, and turned on by default.

And in August Microsoft proudly pointed to results of a (MS commissioned) study by NSSLabs, which stated that IE8 blocked 81% of malware download attempts vs. 27% for FF3 (and even less for other browsers) and 83% of phishing attacks vs. 80% for FF3 (and 54% for Opera 10 and less for Chrome and Safari).

So there you have it, IE8 is the safest browser around, no? Well, that would be jumping to conclusions; IE8 still has it’s fair share of browser security issues (but don’t they all) and the dreaded security-hole called ActiveX is still supported as well. Let’s just focus at how IE8 tries to protect you from malicious websites and compare that functionality with what the competition has to offer.

Smartscreen Filter

Smartscreen filter is the name for the Microsoft technology that uses an “in-the-cloud reputation database” which is contacted by the browser to assess the trustworthiness of a URL. Using that information, access to dangerous sites and downloads of malware can be blocked. The system is very similar to Google Safe Browsing that is implemented in Firefox, Chrome and Safari, but Smartscreen seems to be better in stopping malware from being downloaded. On the other hand the 2nd NSSlabs-study deemed both as effective when it comes to blocking access to phishing sites. Based on these (MS sponsored) results one could conclude that IE8 might have an advantage over the competition, but I for one would be very interested in an updated version of these tests with cooperation from the other browser-makers.

XSS-filter

IE8’s XSS-filter offers protection against type1 cross-site scripting attacks. Although it offers no protection against (less common) type0 and type2 xss-attacks, the mere fact that IE8 does offer out of the box XSS-protection is a big thing. Except … except apperantly there’s a serious bug in IE8’s XSS-filter, that can be abused to do cross-site scripting. Microsoft has not yet confirmed or fixed the bug,¬† leading some sites (e.g. Google) to disable the XSS-filter by adding “X-XSS-Protection: 0” to the http response header. Now isn’t that ironic?

Clickjacking defense

Microsoft also included clickjacking defense in IE8, by letting website owners define whether or not their pages are allowed to be included in (i)frames. This can be done by simply adding “x-frame-options” to the http response header with values “deny” to deny a page from being shown in any frame and “sameorigin” to limit framing to pages from the same domain. x-frame-options however does not protect against clickjacking with flash or other embeds.

But where’s the competition?

So what’s available in Firefox, Chrome and Safari apart from the Google Safe Browsing implementation? Nothing much up until now, I’m afraid …

At Mozilla smart guys are working on “Content security policy“. CSP is a declarative server-driven anti-XSS framework, with policies being pushed through HTTP headers. Although the policy may require non-trivial website changes because inline scripts will be disallowed by default, it certainly has potential (to the extend Microsoft is said to be interested). But CSP is not there yet, now is it?

Over at Google, engineers are including (type1) XSS-protection and support for the Strict Transport Security spec (forcing a browser to load a site only over HTTPS by issuing an http response header) in the dev-channel builds of Chrome 4. As some may have noticed while looking for Google Talk’s chatback badge last week, x-frame-options (as anti-clickjacking measure) has already been implemented in Safari4 and Chrome3 as well. So especially Google is trying to make some serious progress, but Chrome 4 can hardly be considered granny-ready, can it?

That leaves us Firefox with the NoScript extension, but I’ll come back to that combination in a minute.

IE8 the safest browser?

OK, this might hurt, but let’s give credit where credit is due; IE8 indeed seems to offer the best out of the box protection against malicious websites. It is the only browser to come with good phishing- and malware-blocking (Smartscreen) combined with (limited and currently broken) protection against some types of XSS and clickjacking-attacks. So thank you Redmond for setting the example!

The only alternative: Firefox + NoScript

Firefox does not offer the out of the box protection IE8 does, but when combined with the NoScript extension, it really is the only readily available alternative (Lynx not withstanding). NoScript offers superior protection against XSS, clickjacking and a host of other threats.

Even if you’re only vaguely security-conscious, installing Firefox and NoScript should really be your first choice. Depending on the level of protection you want, you can use the default but disruptive whitelist configuration (which blocks all javascript and flash) or switch to the less secure “Allow scripts globally” mode. But whatever configuration you choose, anti-XSS and clickjacking protection are always enabled.

It really is beyond me why NoScript’s Clearclick and anti-xss aren’t in Firefox by default, especially since they seem complementary to CSP, as they’re barely disruptive for a novice user and (last but not least) as Mozilla could easily one-up Microsoft this way? Anyone?

Warning: your computer might be infected!

noscript logo. lelijk beestje, dat script-monsterWarning: your computer might be infected while surfing the web! Because these days web criminals aren’t just attacking government or corporate servers any more, but your browser as well. That way they can steal/ manipulate your data or install other malware. Most of these attacks happen while you are surfing and all the anti-virus software and spyware-scanners in the world will not fully protect your system and data (as Clopin found out while cleaning multiple PC’s of his family). The good news? There are only two big threats: malicious javascript and your own utter stupidity. And both can easily be countered.

Although stupidity is normal, you should try to live by one simple rule: don’t download software. Just don’t. And if you really must, only install if it comes recommended by at least one trusted source such as a computer-literate friend or a high-profile tech website. But don’t download software because a flashing red text on some obscure website tells you your computer is “infected”. Don’t “install a new version of Flash Player” to see that free porn movie. Don’t download, don’t install. Don’t!

Protecting against evil javascript (and malicious html, css, flash, java, …) is another issue. Attacks such as XSS, XSRF or clickjacking are barely visible. You’ll be happily surfing, clicking hyperlinks left and right, logging into your favorite web-apps and before you know it your data has been stolen or tampered, a password was reset or someone gained access to one of your online accounts. Entirely disabling javascript is not an option (you need it for most of modern web-applications to run), but if you’re a security-conscious Firefox-user there’s an easy solution; Noscript.

Noscript is a Firefox-addon that simply blocks all code (Javascript, Flash, Java and Silverlight) from being executed, protecting you by default against almost all types of browser-based attack (“almost”, as I’ve seen a nice proof-of-concept of a history-stealing web-page that only uses CSS-trickery, which Noscript can’t block). If you’re on a site you trust, you simply tell Noscript to temporary or permanently allow javascript -and other code- for that site and you’re back in web2.0-land. It may take some getting used to (a.o. to build a good permanent whitelist to allow your default sites to function), but it’s a great tool that can even double as a flashblock and (to some extend) adblock plus replacement!

So, to summarize; don’t install software and install Noscript and all will (probably) be well.