The document discusses the evolution of client-side security, specifically focusing on vulnerabilities such as XSS and the necessity for secure coding standards. It highlights challenges posed by modern JavaScript frameworks and the inadequacy of traditional security tools for analyzing complex JavaScript code. The document emphasizes the importance of implementing sophisticated coding techniques and dynamic analysis for effective security in a rapidly evolving landscape.

1. OWASP Taiwan Day 2017
Client Side Security And Testing Tools
(Evolution of)
david.cervigni@mindedsecurity.com

2. About me
 10+ yeas of development
 Software Security Enthusiast
 Securing SDLC
 Secure coding trainer/reviewer
david.cervigni@mindedsecurity.com

3. JS Security, topics:
• Evolution of client technologies (security)
• Why is always important
• Why is always difficult
• Techniques and tools to avoid vulnerabilities

4. Client security is vast

5. XSS is always dangerous!
• XSRF protection bypass
• Cookies/session stealing
• Defacement
• Password/credential stealing
• Enumeration
…
Attacker OWNS our website,
and still:
Consequences:

6. Anti XSS approaches:
Classic:
• Validation
• Filtering
• HTML Encoding
• Encoding lib + Contextual Encoding
• ?
<div onclick="showError ('<%=
Encoder.encodeForHtml(Encoder.encodeForJavaScript(
request.getParameter("error")%>')))" >
An error occurred ....</div>
Requires:
• Secure coding standards (enforced!)
• Knowledge
• Design (use the right libs)
…still error prone!

7. Anti XSS evolution:
Contextual encoding templates:
• Very strict
• Hard to encode in nested contexts / double encoding

8. Anti XSS evolution/2:
Mitigations:
• CPC: Content Security Policy
• ECMAScript security features (e.g. strict mode)
• Sandboxing JS (Google CAJA, sanitizer libraries)
• Anti XSS browser features WAF
Requires:
• Secure Application Design
• Third parties JS libraries compatibility?
• Legacy systems?
…still not fully secure (evasion)

9. So…Problem Solved?
Sources:
https://snyk.io/blog/xss-attacks-the-next-wave/
https://nvd.nist.gov/vuln/detail/CVE-2017-1160
“DOM-Based XSS is notoriously hard to
detect, as the server never gets a chance
to see the attack taking place.[…]”

10. New challenges:
Modern JS frameworks:

11. *Source: https://2017.appsec.eu/slides-and-videos
"Don’t trust the DOM: Bypassing XSS mitigations via Script
gadgets "
XSS Mitigation bypass
On:
Angular (1.x), Polymer (1.x), React, jQuery, jQuery UI, jQuery Mobile, Vue, Aurelia,
Underscore / Backbone, Knockout, Ember, Closure Library, Ractive.js, Dojo Toolkit,
RequireJS, Bootstrap…

12. • SPA: Single Page Applications
• Mainly HTML & JavaScript (not anymore flash)
• Frameworks: Angular, React…
• Third party libraries (JQuery and others)
• High degree of integration: portals/services
Why is always more important?

13. • Big codebases
• JavaScript is not easy to read: manual review
• Developing and Quality Assure for JavaScript and client components is
DIFFICULT, time consuming and error prone.
• Classic security tools use SCA (Static Code Analysis) that leads to :
1. Too many false positives
2. Too many false negatives
Why is always more difficult?

14. ❑ Sources: the input data that
can be directly or indirectly
controlled by an attacker.
❑ Filters: operations on Sources
which change the content or check
for specific structures/values.
❑ Sinks: potentially dangerous
functions the can be abused to take
advantage of some kind of
exploitation.
Code Flow and Taint analysis
<script>
var l = location.href;
var user = l.substring(l.indexOf(“user”));
document.write(“Hello, ” + user);
</script>
Tainted Source
Sink
The process of following the
tainted value from source to
sink is known as Taint
Propagation.

15. Tools for JS Code analysis
SCA, static code analysis:
• Heavy
• Difficult
• Lower accuracy (false positives)
• Adaptability (false negatives…needs custom rules)
• Broad language support
Dynamic code analysis/IAST:
• Requires instrumentation
• More accurate
• Fuzzing capabilities!
SDLC
and
Automation (CI)

16. DOM XSS Wiki:
http://code.google.com/p/domxsswiki/wiki/LocationSources
Attacker controls all parts of a location except the victim hostname.
path/to/page.ext/ PathInfo ?Query=String #Hash=valuehttp://hostname/
He can force a user to visit a forged url address.!
Direct Input Sources: Location

17. Cookie value could have been instantiated somewhere else and retrieved
on another page. Its value can be accessed/modified with:
❑ document.cookie:
<script>
var cvalue = document.cookie;
var cstart = cvalue.indexOf(“username=");
cvalue = unescape(cvalue.substring(cstart+9, cstart+9+length));
alert(“Welcome ” + cvalue);
</script>
The attacker could force a malicious cookie value!
Indirect Input Sources: Cookies

18. DEMO,
Q/A,
THANKS!
AND NOW…

19. Tools for JS Code analysis