Chad Tindel's Prevoty Presentation at the 20150730 NYC Java SIG

1. Beyond the
Perimeter
PREVOTY
Chad Tindel
Principal Solution Architect
chad@prevoty.com
@ctindel
July 2015

2. Hubsan X4 Quadcopter With Video
http://info.prevoty.com/win

9. Evolution of
security

10. ENTERPRISE APPS
• Dynamic and static
• Developed in many languages
• Deployed to irons and clouds

11. SECURITY PILLARS / TIME
PILLAR CONTROLS VALUE / TIME
NETWORK Network / Web Firewalls
Perimeter has changed,
assume internal = external
ENDPOINT
Patches / Intrusion Detection +-
Prevention
Critical bugs in common
infrastructure (heartbleed)
APPLICATION SAST / DAST / People
Running a testing tool doesn’t
actually fix code

13. DEFENSES HAVEN’T SCALED
• Volumetric defense isn’t sufficient
• Zero days evade pattern matching
• Security testing isn’t impactful

14. 84% OF ATTACKS TARGET
APPLICATIONS
GARTNER 2013

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. 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

18. 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

19. 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. New attacks found all the time

21. A1: SQL Injection
1=1 is always true
txtUserName = getRequestString("UserName");
txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserName;
What if someone supplies the username “ctindel or 1=1” ?
Then this statement will select all user rows:
SELECT UserId, Name, Password FROM Users WHERE UserId =
ctindel or 1=1
3=2+1 is also always true
Sin(0) = cos(PI) + 1 is also always true

22. A1: SQL Injection
What if someone supplies the username “ctindel; DROP TABLE Users”

23. A1: SQL Injection
Exploits of a Mom
https://xkcd.com/327/

24. A1: SQL Injection
Primary Defenses
Prepared
Statements and
Parameterized
Queries
Prepared Statements (Parameterized Queries)
String custname = request.getParameter("customerName”);
String query = "SELECT account_balance FROM user_data WHERE
user_name = ? ";
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, custname);
ResultSet results = pstmt.executeQuery( );

25. A1: SQL Injection
Primary Defenses
Stored Procedures
String custname = request.getParameter("customerName");
try {
CallableStatement cs = connection.prepareCall("{call
sp_getAccountBalance(?)}");
cs.setString(1, custname);
ResultSet results = cs.executeQuery();
// … result set handling
} catch (SQLException se) {
// … logging and error handling
}

26. A3: Cross-site
Scripting (XSS)
Cross-Site Scripting (XSS) attacks occur when:
1. Data enters a Web application through an untrusted source, most
frequently a web request.
2. The data is included in dynamic content that is sent to a web user
without being validated for malicious content.
The most severe XSS attacks involve disclosure of the user’s session
cookie, allowing an attacker to hijack the user’s session and take over the
account.
<script>alert(document.cookie)</script>
“><script>alert(document.cookie)</script>
"%3cscript%3ealert(document.cookie)%3c/script%3e
<scr<script>ipt>alert(document.cookie)</script>
<body onload=alert(document.cookie)>
<b onmouseover=alert(document.cookie)>click me!</b>
If your method of XSS protection uses pattern matching or regex, it
is most likely vulnerable to fuzzing.

27. A3: Cross-site
Scripting (XSS)
1. Stored XSS attacks are those where the injected script is permanently
stored on the target servers, such as in a database, in a message forum,
visitor log, comment field, etc. The victim then retrieves the malicious script
from the server when it requests the stored information. Stored XSS is also
sometimes referred to as Persistent or Type-I XSS.
1. Reflected XSS attacks are those where the injected script is reflected off the
web server, such as in an error message, search result, or any other response
that includes some or all of the input sent to the server as part of the request.
Reflected attacks are delivered to victims via another route, such as in an
e-mail message, or on some other web site. Reflected XSS is also sometimes
referred to as Non-Persistent or Type-II XSS.
1. DOM-Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS
attack wherein the attack payload is executed as a result of modifying the
DOM “environment” in the victim’s browser used by the original client side
script, so that the client side code runs in an “unexpected” manner.

28. A3: Cross-site
Scripting (XSS)
What does the browser interpret this as?
$=~[];$={___:++$,$$$$:(![]+"")[$],__$:++$,$_$_:(![]+"")[$],_$_:++$,$_
$$:({}+"")[$],$$_$:($[$]+"")[$],_$$:++$,$$$_:(!""+"")[$],$__:++$,$_$:++
$,$$__:({}+"")[$],$$_:++$,$$$:++$,$___:++$,$__$:++$};$.$_=($.$_=$
+"")[$.$_$]+($._$=$.$_[$.__$])+($.$$=($.$+"")[$.__$])+((!$)+"")[$._$$]
+($.__=$.$_[$.$$_])+($.$=(!""+"")[$.__$])+($._=(!""+"")[$._$_])+$.$_[$
.$_$]+$.__+$._$+$.$;$.$$=$.$+(!""+"")[$._$$]+$.__+$._+$.$+$.$$;$.$
=($.___)[$.$_][$.$_];$.$($.$($.$$+"""+$.$_$_+(![]+"")[$._$_]+$.$$$_+
""+$.__$+$.$$_+$._$_+$.__+"(""+$.__$+$.__$+$.___+$.$$$_+(![
]+"")[$._$_]+(![]+"")[$._$_]+$._$+","+$.$__+$.___+""+$.__$+$.__$
+$.$$_+$.$$$_+""+$.__$+$.$$_+$.$$$+""+$.$__+$.___+""+$.__$
+$._$$+$.__$+$._$+""+$.__$+$.$$_+$._$_+""+$.__$+$.$_$+$._$
$+""+$.$__+$.___+""+$.__$+$.___+$._$$+""+$.__$+$.$_$+$.__$
+$.__+""+$.__$+$.$$$+$.__$+"""+$.$__+$.___+")"+""")())();

29. A3: Cross-site
Scripting (XSS)
alert("Hello, New York City”);

30. http://utf-8.jp/public/jjencode.html

31. A3: XSS
Primary Defenses
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 “&amp;”
and “<“ to “&lt;” 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" ) );

32. A8: Cross-site
Request Forgery
(CSRF)
An attack that forces an end user to execute unwanted
actions on a web application in which they're currently
authenticated.
CSRF attacks specifically target state-changing
requests, not theft of data, since the attacker has no
way to see the response to the forged request.

33. A8: CSRF
Primary Defenses
The preferred option is to include the unique token in a hidden form field or
via a session cookie. This causes the value to be sent in the body of the HTTP
request, avoiding its inclusion in the URL, which is subject to exposure.
The token should be a function of things like the sessionID, Form Action
Parameter, a time-based nonce, and some expiration TTL. When the form is
submitted the token will be checked for validity and immediately invalidated so that
it can only be used once.
OWASP Publishes a Java library called CSRFGuard which is integrated through
the use of JavaEE Filter.
https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project
The token approach will break down when the site on which it is deployed contains
XSS (Cross-Site Scripting) vulnerabilities. If attackers can XSS your site, they
can read the content and extract the token you are using.

34. There Is No
Silver Bullet
In App Sec
Root Causes
• Perimeter-based controls (WAFs) lack context to make reliable
decisions (high % of false positives)
• Pattern matching doesn’t work: computationally inexpensive to
generate millions of fuzzed attack payloads
• Developers are continuously building new products/features
(increasing attack surface)
Top 2 Challenges
1. There is no scalable solution to defeat the vulnerability backlog and
growing legacy codebase
2. There is no real-time visibility about application attacks: who has the
attack payload and metadata?
Popular topics that
security teams must
address when
building out an
Application Security
program

35. Non-invasive
Remediation
For Java 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

36. Non-invasive
Remediation
For Java Apps
HDIV
http://www.hdiv.org/

37. Non-invasive
Remediation
For Java Apps
HP App Defender

38. Prevoty
Architecture
Prevoty has
developed framework
plugins for Java,
.NET and Ruby on
Rails
SDKs are available
for nearly any and
every language
C# Java .NET / IIS node.js Go PHP Python Ruby

39. Introducing Prevoty Runtime Application Self-Protection (RASP)
Prevoty delivers application security from
inside the app itself, leveraging our
contextual and behavioral engine to
automatically secure content, queries and
users in real-time
39
Dynamic
Built in-house
& externally
Distributed
Database
Internal
Employees
Firewall
incl. WAFs
External
Employees
Cloud, Web Services, Partner Apps,
SAML
External Data
Services
User Generated
Content
Mobile & Multi-
device
Users

40. The Prevoty
Difference
Root Causes Addressed By Prevoty
• Prevoty applies the contextually correct level of security to prevent
XSS, SQLi and CSRF (lives in your applications)
• Prevoty doesn’t rely on pattern matching - it’s built on top of unique
content/query virtualization engines
• Prevoty makes it easy for developers to integrate this level of security
via plugins for all major application frameworks
Top 2 Challenges Solved By Prevoty
1. Prevoty can significantly diminish vulnerability backlogs and SSDLC
churn; it can be dropped in to provide immediate relief for legacy
2. Prevoty gives you attack visibility: who + what + when + where
How Prevoty
addresses the
challenges of
Application Security

41. Unparalleled insights into what
threats are actually hitting your
applications at runtime
Includes IP address, session information
(including User ID if available), cookie detail
IDENTIFY THE ORIGIN OF THE THREAT
WHO
Contents of the payload, payload intelligence
PROVIDE DETAILS OF THE NATURE OF
THE THREAT
WHAT
Timestamp (down to the nanosecond)
WHEN DID THE ATTACK TAKE PLACE
WHEN
URL for web applications, stack trace for SQL
queries
WHERE THE EXPLOIT HAPPENED IN
YOUR APPLICATIONS
WHERE
PREVOTY
APPLICATION
SECURITY
MONITORING
(ASM)

42. Real-time application threat
intelligence on attacks in
progress can easily be delivered
to:
- SIEM’s (such as Splunk)
- NGFW’s
- IPS’s
- WAF’s
PREVOTY
APPLICATION
SECURITY
MONITORING

43. Thank
You
Learn more at prevoty.com
PREVOTY