October 2013 OWASP Belgium Chapter Meeting Wrap-UP

I’m just back from the first OWASP Belgium Chapter meeting since the holidays are over. This was already the third event in 2013. The next event will be scheduled in December. This time, two great speakers were present. The first one was Giorgio Maone who presented “NoScript for Developers“. Giorgio is the author of NoScript. For sure, you already heard some good feedbacks about this very popular Firefox extension. To briefly resume the long list of features, this is a Javascript permissions manager and content blocker. It can protect you against classic web attacks like XSS or CRSF. If the tool is very helpful on a daily basis, it can also be very intrusive while surfing on badly developed websites and become a nightmare. “Bad” mean in this case, that they implement techniques that trigger NoScript and prevent a smooth web surfing. The talk proposed by Giorgio was dedicated to developers to make them aware of tips to prevent such kind of situation.

The first issue reported by Giorgio is the mess found in some webpages. Just by visiting a single URL, you can access content spread on multiple CDNs, multiple trackers (like Google Analytics) or advertisement networks. Try to keep things clear and simple (after all, it should always be like this). If, to be able to browse a website, you have to disable completely NoScript, where is the protection? Another recommendation is to avoid like pest simple error pages with a dump message like “Please enable Javascript“, instead be clear about your requirements. Also, avoid nested inclusions: Do not load scripts from scripts. A question from the audience: “What about an ‘allow-recursive’ option?“. It does not exists, the only way to prevent this is to temporary disable the extension… The next tip was to avoid loading script libraries directly from the source code repository. They will be blocked by NoScript. Good examples are github.com or code.google.com. Never allow these domaines otherwise you will be vulnerable to any malicious script uploaded on them.

Then, Giorgio explained a cool NoScript feature: surrogates scripts. This allows the replacement of external scripts (blocked) by a user-provided scripts which will be executed instead of the original ones. Have a look at the link for more details. Brilliant feature! NoScript has also an anti-XSS filter which uses the Gecko HTML parser and the SpiderMonkey Javascript engine to check for malicious code. It also checks for exotic encoding (like the one used by eBay). Giorgio also detected that sometimes, web developers pass some code in URLS! (This was the case with Youtube a few weeks ago). URLs are made to post data and not code! This is also blocked by NoScript. Thinking about Base64 obfuscation? Forget it, NoScript decodes Base64! Another feature is the HTTPS enhancement with automatic or manual cookie management (to protect against the cookie monster attacks). HTTPS can also be enforced. Here again a warning for developers: avoid fallback to HTTP otherwise you will enter an endless loop!

ABE (or “Automatic Boundaries Enforcer“) is like a WAF in the browser, it provides a CRSF filter and the default rule to block cross-zone request to protect LAN and local resources like SOHO routers & firewalls. Advice for developers: Experiment protecting your own applications with ABE and avoid cross-zone requests. NoScript works with two zones: the Internet and the private space (based on RFC1918). As a final remark from Giorgio, don’t try the NoScript alternatives for Chrome, they don’t work at all! You find an issue with NoScript? Don’t report it via the social media but instead use a private email address and send sensitive data encrypted with PGP. Good talk with nice recommendation to build NoScript-compliant websites

After a few minutes break, Mario Heiderich came with a brand new talk presented for the first time! The title was a little bit strange:  “JSMVCOMFG – To sternly look at JavaScript MVC and Templating Frameworks“. Mario has a huge background with web applications testing. His new research focused on Javascript Template Frameworks like CanJS, EmberJS or AngularJS. Why? All those products promise a better world to developers: “Be more productive“, “Makes developer’s life easier“, etc. But are they really secure? They expand the “DOM“, they often use script templates or “data blocks” (from HTML5) with lot of “{{value}}” or “mustaches” as says Mario ironically. They also use often custom elements like <thisismycode>. To have an idea of how they work, Mario mentioned the website TodoMVC which proposes to help developers to select a MV* framework: it shows the same application but with different codes.

To test the security of those frameworks, Mario started with some “pokes“. He showed how easy it was to compromise well-known frameworks. A first conclusion was that most of them did not work with CSP (“Content Security Policy“) enabled. But he also demonstrated that AngularJS was able to bypass this security technique! Lot of source code examples were reviewed. But the most interesting part (IMHO) was the demonstration of how to abuse Chrome Packaged Apps. Google describe them as following:

“Packaged apps deliver an experience as capable as a native app, but as safe as a web page. Just like web apps, packaged apps are written in HTML5, JavaScript, and CSS. But packaged apps look and behave like native apps, and they have native-like capabilities that are much more powerful than those available to web apps.“

Really? “as capable as native app, but as safe as a web page“… Remember that AngularJS is able to bypass CFP is (as seen in previous demos). So, Mario demonstrated how to use this issue to escalate privileges of his rogue packaged app! Brilliant! Think about an app accessing your microphone, your drives, your webcam etc… The problem in this case: it’s not a bug but a feature. If Google changes the way Chrome is working at the moment, most applications will be broken! The final step for Mario was to build a metric to be able to classify the different frameworks (he tested 12 of them). All the details are available on this wiki page: code.google.com/p/mustache-security. Have a look and feel free to share your findings, Mario is looking for some help!

That’s all for tonight… See you at a next event!