15. 90% OF APPS HAVE >1 CRITICAL
BUG
HP PROTECT 2014
16. AVERAGE OF 138 DAYS TO FIX 1
SQL INJECTION
HP PROTECT 2014
17. OWASP Top-10
Open Web
Application Security
Project Top 10
Application
Vulnerabilities
A1 SQL Injection A6 Sensitive Data Exposure
A2
Broken Authentication and Session
Management
A7
Missing Function Level Access
Control
A3 Cross-Site Scripting A8
Cross Site Request Forgery
(CSRF)
A4 Insecure Direct Object References A9
Using Known Vulnerable
Components
A5 Security Misconfiguration A10
Unvalidated Redirects and
Forwards
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
18. OWASP Top-10
Open Web
Application Security
Project Top 10
Application
Vulnerabilities
“97 percent of data breaches worldwide are still due
to an SQL injection somewhere along the line”
-Neira Jones, Barclays Head of Payment Security for
Barclaycard.
Cross-site scripting carried out on websites accounted
for roughly 84% of all security vulnerabilities
documented by Symantec
Secure cloud hosting firm FireHost reveals that in the
first quarter of 2013, the volume of Cross-Site Request
Forgery (CSRF) attacks increased by 132% compared
to the same period of 2012.
20. CONTROLS, EVOLVED
OLD CONTROLS NEW CONTROLS
Network / Web Firewalls
Micro-Segmentation
Assume the attackers will get in
Patches / Intrusion Systems
Micro-Virtualization
Assume the process will execute
SASTs / DASTs / People
Runtime Application Security
Assume the app will be hit
22. A3: XSS
Defense by
Encoding
1. Never Insert Untrusted Data directly in a script, inside an HTML comment, in
an attribute name, in a tag name, or directly in CSS. Never accept actual
JavaScript code from an untrusted source and then run it.
2. Encode untrusted data before reflecting it back out. HTML Escape Before
Inserting Untrusted Data into HTML Element Content (convert “&” to “&”
and “<“ to “<” etc).
OWASP Publishes a Java Encoder you can use in your app to help with a lot of
this:
https://www.owasp.org/index.php/OWASP_Java_Encoder_Project
https://github.com/OWASP/owasp-java-encoder/
String safe = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) );
String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter(
"input" ) );
String safe = ESAPI.encoder().encodeForJavaScript( request.getParameter(
"input" ) );
String safe = ESAPI.encoder().encodeForCSS( request.getParameter( "input" ) );
23. A3: XSS
Problems with
encoding
1. Requires Developers to properly encode all untrusted input which if we
could trust them to do that all the time, we wouldn’t have these bugs in the first
place.
2. Complicated to choose the correct encoding mechanism before reflecting
it back out. Need to consciously choose the correct encoding scheme
(encodeForHTML, encodeForHTMLAttribute, encodeForJavascript, etc) and in
the rush to get new features out with modern development timelines and agile
lifecycles it is easy to make a mistake here.
3. Requires you to make code changes to the application so how will you do
this to protect legacy apps and third party apps which are showing open
vulnerabilities in your scanning tools?
4. Does not give you data/visibility on whether or not there was an
attempted attack so how will you generate metrics and reports on which
applications are under attack, what kinds of attacks are happening, and whom
is attacking you?
5. Is not commercially supported by a vendor so on whom will your enterprise
depend for bug fixes in the encoding library? Look at the node-esapi module
which was last updated two years ago and is still version 0.0.1
https://www.npmjs.com/package/node-esapi
25. A3: XSS
Problems with
Regex
1. Writing regex that covers every possible case is a challenge and leads a messy set of
hard to maintain patterns. Just look at all these examples that OWASP publishes:
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
2. Hackers are constantly fuzzing and obfuscating 0-day attacks to find new ways
through the statically defined set of Regex patterns. Within 2 hours of the Microsoft Edge
browser being shipped a vulnerability was found in the built-in XSS filter.
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6058
https://technet.microsoft.com/library/security/ms15-107
https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-9900/opbyp-1/Microsoft-
Internet-Explorer.html
3. Regex is SLOOOOOW and subject to DOS attacks (ReDoS):
https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS
4. New tags come out with new standards so if your app was written during the days of
HTML4, you will need to go update your regex to handle new ways of injecting things,
like HTML5 <AUDIO> and <VIDEO> tags. How easy is that to do for an app that is 8
years old and the developer has moved on?
5. False Positives are common so the pattern based approach will probably break your
app in unintended ways and require frequent tuning.
26. Non-invasive
Remediation
For Apps
Gartner Maverick Research
“Runtime Application Self-Protection (RASP)”
“Applications should not be delegating — as is done today — most of their runtime
protection to external devices. Applications should be capable of self-protection —
that is, have protection features built into the application runtime
environment.
These features should see all data coming in and out of the application, all events
affecting the application, all executed instructions, and all database access. Once
RASP is deployed into production, the application runtime environment should be
able to detect attacks and protect applications with a high level of assurance.”
• Be able to protect applications by detecting and blocking attacks.
• Have deep visibility into application logic flow and data flow, configuration,
executed instructions and data processing to accurately identify attacks.
• Be instrumented into the application runtime environment. This instrumentation
should be noninvasive or require no/minimal invasiveness into application code.
- Joseph Feiman, Gartner Analyst
28. What is
LANGSEC
• Language-Theoretic Security is an emerging methodology that treats code
patterns and data formats as languages and their grammars for the purpose of
preventing the introduction of malicious code into software
• Pioneered by Dr. Sergey Bratus, Meredith L. Patterson, and the late Len
Sassaman
“LANGSEC posits that the only path to trustworthy software that takes
untrusted inputs is treating all valid or expected inputs as a formal language,
and the respective input-handling routines as a recognizer for that language. The
recognition must be feasible, and the recognizer must match the language in
required computation power.
When input handling is done in adhoc way, the de facto recognizer, i.e. the
input recognition and validation code ends up scattered throughout the
program, does not match the programmers' assumptions about safety and validity
of data, and thus provides ample opportunities for exploitation.”
30. Lexical Analysis
Letters, Numbers
Punctuation
Words
i h a v e a f l a t
Syntactic Analysis Sentences “i have a flat”
Code Generator
Domain
Intent
Context
Automobile
Driving
Transportation
Transformer Policies i have a flat tire
Regular
Expression
LANGSEC
31. LANGSEC
Advantages
1. Not vulnerable to false positives because the formal grammar will tell us immediately
whether input from the user is an attack or not
2. Not vulnerable to 0-day attacks because it is not vulnerable to fuzzing or obfuscation
attacks.
3. Ultra-fast performance because it is done using custom tokenizers, scanners, and
parsers for the exact problem domain
4. Can generate actionable data and reports because it tells us when there was an attack
against an application and the exact details of the attack itself.
Real Examples in ACME
