With Autoptimize 2.7.7 released on August the 23rd and having been pushed to all sites that were still on 2.7.0-2.7.6 by the WordPress plugins team on Aug. 30th and 31th, resulting in just under one million downloads in 8 days time, it is now the moment for a small debrief of the security issues that were fixed in this version. 2.7.7 fixed two vulnerabilities, one authenticated cross-site scripting and one arbitrary file upload.
XSS:
Problem: administrator users were able leave JavaScript in the exclusion-fields for CSS and JS optimization, leading that JS to be executed when the page was (re-)loaded.
Risk: This could be abused by one administrator to execute JS against another administrator.
Solution: This was fixed by applying esc_html (to become esc_attr in the next version as suggested by George Stephanis) to escape the JS-code and avoid it getting executed.
Arbitrary File Upload:
Problem: the code that processes Critical CSS settings imports did insufficient checks to ensure no malicious files were uploaded as it lacked a user capability check, did not check file extension of to uploaded file to be zip and did not check the contents of the zip-file. It did however check for a correct nonce for that specific action.
Risk: this could lead to authenticated attackers uploading PHP-files that could be executed, but that risk was very much limited by the nonce-check (which all exploits I have seen happily ignore).
Solution: the code has been updated to do a capability check, to make sure the file uploaded is a zip-file and most importantly to delete any unknown file found immediately after unzipping (based on an list of known-good files).
A big thank you to the two security researchers (Erin Germ for the XSS and an anonymous whitehatter for the file upload problem) who reported these vulnerabilities in a responsible manner and to the WordPress plugin team for their invaluable help in keeping our users safe.
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 vulnerabilitiesin 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;
session-cookies are set with the HTTPOnly-flag so XSS should not be an issue
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!
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:
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:
With 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.
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 type1cross-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 clickjackingdefense 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-protectionand support for theStrict 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 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.
With Autoptimize 2.7.7 released on August the 23rd and having been pushed to all sites that were still on 2.7.0-2.7.6 by the WordPress plugins team on Aug. 30th and 31th, resulting in just under one million downloads in 8 days time, it is now the moment for a small debrief of the security issues that were fixed in this version.
