http://lanyrd.com/2012/yuiconf/szwrf/
Everyone agrees that application security is of crucial importance, and attacks on web frontends are getting more frequent, sophisticated, and dangerous. Yet the area of security testing of frontend and YUI-based applications has so far received little attention. This talk highlights the need to embed security testing in the standard repertoire of every Javascript and YUI developer, alongside with functionality and performance tests. We will emphasize the security testing as part of development workflow - writing and running tests alongside creating the code. Our main goal is to attract the YUI community's attention to this grey area and start a discussion and cooperation of webappsec and YUI worlds.
1. Security Testing Of YUI Powered Applications
November 15, 2012 YUIConf 2012 Dmitry Savintsev, Albert Yu
2. Who we are
Dmitry Savintsev
- Yahoo Developer / Paranoid of 12+ years
- Assembly -> C++ -> PHP -> Javascript
- @dimisec, github.com/dmitris
Albert Yu
- Yahoo Engineer / Paranoid since 2005
- @yukinying
3. Agenda:
Why Security Testing
JavaScript Testing vs. Pentesting
Tools of Trade
Testing for XSS
Static Code Analysis
The Road Ahead
4. Testing Well-Known Benefits
States and validates application behavior
“runnable documentation”
No tests – not maintainable
5. Security defects – highest negative impact
Users’ data at stake!
Your app WILL be tested by the world
6. Sad state of web application security
XSS is prevailing
Server- and OS-level Javascript
Need to pull all stops
7. Modern Javascript Testing:
Unit, functional integration testing
Code coverage / reporting tools
Integral part of the CI workflow
8. Pentesting
• Established practice in webappsec world
• Combination of manual poking & use of
different tools (ex. Burp Proxy)
• Flourishing consulting business
10. JS Dev and Webappsec need each other
• Javascript eats the world
• Just look at Yahoo! (Cocktails…)
• Mobile / alt screens huge impetus
• Attack surface rapidly expanding
• Dire shortage of manpower and talent
11. Security testing challenges
• “End of scanning”
• Difficult-to-impossible to test
automatically
• “surface discovery” – mapping FE apps
• Highly situation / context dependent
12. Code and feature coverage problem
Testing needs to be guided through the app
Testing and coding in close proximity
Power to the developers!!
13. Tools for (security) testing
• Selenium / Webdriver
• Greatly matured in the recent years
• JS bindings still new (only remote server)
• PhantomJS (and Ghostdriver)
• YUI Test
20. JSLint, JSHint
Thanks to NodeJS, now they are available as
CLI tool.
% # JavaScript Good Parts
% npm -g install jslint
% jslint --white --browser
foo.js
% # JavaScript Less Good Parts
% # Better reporting
% npm -g install jshint
21. $ jslint --white --browser yui-debug.js
yui-debug.js
#1 'YUI' was used before it was defined.
if (typeof YUI != 'undefined') { // Line 15, Pos 12
#2 Expected '!==' and instead saw '!='.
if (typeof YUI != 'undefined') { // Line 15, Pos 16
#3 Unexpected dangling '_' in '_YUI'.
YUI._YUI = YUI; // Line 16, Pos 9
$ jshint yui-debug.js
yui-debug.js: line 59, col 9, Redefinition of 'YUI'.
yui-debug.js: line 385, col 26, Missing semicolon.
yui-debug.js: line 617, col 35, 'loader' is already defined.
yui-debug.js: line 632, col 18, Don't make functions within a
loop.
yui-debug.js: line 997, col 17, ['loader'] is better written
in dot notation.
yui-debug.js: line 2210, col 34, Expected an assignment or
function call and instead saw an expression.
22. A Very Rough Benchmark
Disclaimers
1. jQuery and YUI benchmark are not correct as the code does not stored on
the path that stores Todomvc sample.
2. JSLint stops when it sees critical error or too many errors.
3. Minified code may affect the reporting.
4. No yui-lint customizations.
23. Benchmarks on YUI Gallery
Running yui-lint (custom .jshintrc)
461 gallery modules
42 without any issues
74 warnings in average
86 modules > 100 issues
873 issues in maximum
26. Develop – where we run it now (?)
Commit – where it should be run
Review – and here as well
Merge
Release
27. var express = require('express');
var app = express();
var Y = require('yui/io-base');
app.get('/api*', function(req, res){
var params = require('url').parse(req.url, true);
var url = "http://localhost:3000/json/" +
params.query.question ;
Y.io(url, { on: { complete: function(id, e) {
try {
var json = JSON.parse(e.responseText);
} catch (err) { console.log(err); }
res.end( json.answer + "n" );
} } }); });
app.get('/json/whoami', function(req, res)
{ res.end('{"answer":"bob"}'); });
app.get('/json/*', function(req, res)
{ res.end("Error: I don't understand"); });
app.listen(3000);
28. try {
var json =
JSON.parse(e.responseText);
} catch (err) {
console.log(err); }
res.end( json.answer + "n" );
}
29. JSLINT OUTPUT:
#1 Missing 'use strict' statement.
var params = require('url').parse(req…
#2 'json' was used before it was defined.
try { json = JSON.parse(e.responseText); }
Usually easier to enforce on server side.
Frontend code are harder to enforce:
1. Multiple script blocks
2. Browser compatibilities
3. Excuses ..?
4. Frontend code will not be run on server?
34. ES5 Strict Mode
Opt-in via “use strict” pragma
Option 1: Globally applying on same file/block/eval
block.
"use strict";
YUI.use(...
same script block, eval, file
Option 2: Function level
YUI.use('...’, function(Y){
"use strict";
var a = ...
35. The Big 4
// 1. Global Variable Protection
var dump_this_as_global = function() {
"use strict";
console.log(this.a);
// Err:
// Cannot read property 'a' of
// undefined
};
dump_this_as_global();
dump_this_as_global.call({a:1});
36. // 2. Global Variable Implicit
// Declaration
(function implicit_var() {
"use strict";
for( var obj in list ) { ...
// Err: obj is not defined
})();
console.log(i);
DON’T DO THIS IN NODEJS
37. // 3. function inside function
(function function_function () {
"use strict";
if (1!=2) function dummy() { };
// Err: functions can only be
// declared at top level or
// immediately within
// another function
})();
38. // 4. Duplicated property
(function duplicate() {
"use strict";
var a = {b:1, b:2};
console.log(a.b);
})();
http://www.flickr.com/photos/djackmanson/489401961/Reviewer to complain? Or someone hurt ?
Consider adding it into your test script today and enforce it
http://www.flickr.com/photos/katjung/1199062421/
Why these are bad
Why these are bad
Lastly, we could talk about some interesting findings on use strictAmazon has a JS flattening code which accidentally included use strict in the middle of it (since one file has it) and it breaks another scriptMozilla has a MDN page that provides very comprehensive details on use strict. However, the JS on that page is not having strict mode enabled.
When you set to do at least some security-related tests, you have to consider more carefully edge cases, unintended usage of the application (interface, function etc.), assumptions made about the types of usage and input, whether protections are made, how they are implemented, and whether the implementation of those protection measures / controls is done in a way that allows to understand and verify in sufficient isolation.
