1. Protecting the code of Web Applications
Pedro Fortuna
Co-founder and CTO
ISEP, June 19th 2013

2. Agenda
Web Application Security
JScrambler
JavaScript Obfuscation

3. +web
NEXT
Web Application Security

4. Where things went wrong?
Web Browser
Web Server
GET /index.html
static text
Content delivery system

5. Where things went wrong?
Web Browser
Web Server
GET /index.html
static text
Content delivery system
Web Browser
Web Server
GET /form.php?id=2&name=pedro%20fortuna
dynamically generated response
Application delivery system 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
<?PHP
$place = 'Peter's Pizza'; print $place;
?> DB
"uma frase aleatória"
"uma frase aleatória"
HTML escaping
<?PHP
$place = 'Peter\'s Pizza'; print $place;
?> DB
PHP string escaping

7. OWASP Top 10 2010 edition A1: Injection A2: Cross-Site Scripting (XSS)
A3: Broken Authentication and Session Management
A4: Insecure Direct Object References
A5: Cross Site Request Forgery (CSRF)
A6: Security Misconfiguration
A7: Failure to Restrict URL Access
A8: Insecure Cryptographic Storage
A9: Insufficient Transport Layer Protection
A10: Unvalidated Redirects and Forwards

8. A1 - Injection
Tricking an application into including unintended commands in the data sent to an interpreter
Injection means…
Take strings and interpret them as commands
SQL, OS Shell, LDAP, XPath, etc…
Interpreters…
Many applications still susceptible
Even though it’s usually very simple to avoid
SQL injection is still quite common
Usually severe. Entire database can usually be read or modified
May also allow full database schema, or account access, or even OS level access
Typical Impact

9. SQL Injection - Illustrated
Account:
SKU:
Account:
SKU:
"SELECT * FROM accounts WHERE acct=‘’ OR 1=1--’"
Account Summary
Acct:
Acct:
Acct:
Acct:
HTTP response  
DB Table  
HTTP request
SQL query
Application Layer
Accounts
Finance
Administration
Transactions
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions
Databases
Legacy Systems
Web Services
Directories
Human Resrcs
Billing
APPLICATION ATTACK
Custom Code
1. Application presents a form to the attacker
2. Attacker sends an attack in the form data
App Server
3. Application forwards attack to the database in a SQL query
Web Server
Hardened OS
4. Database runs query containing attack and sends encrypted results back to application
Network Layer
Firewall
Firewall
5. Application decrypts data as normal and sends results to the user

10. A1 – Avoiding Injection Flaws
Recommendations
Avoid the interpreter entirely, or
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
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

11. A2 – Cross-Site Scripting (XSS)
Raw data from attacker is sent to an innocent user’s browser
Occurs any time…
Stored in database
Reflected from web input (form field, hidden field, URL, etc…)
Sent directly into rich JavaScript client
Raw data…
Try this in your browser – javascript:alert(document.cookie)
Virtually every web application has this problem
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
Typical Impact

12. Cross-Site Scripting (XSS) Illustrated1
Attacker sets the trap – update my profile
Application with stored XSS vulnerability
Hello my name is Peter
<script>
XSSImage=new Image;
XSSImage.src="
</script>
Attacker enters a malicious script into a web page that stores the data on the server
Custom Code
Accounts
Finance
Administration
Transactions
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions 2
Victim views page – sees attacker profile
Script runs inside victim’s browser with full access to the DOM and cookies 3
Script silently sends attacker Victim’s session cookie

13. A2 – Avoiding XSS flaws Recommendations References 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:
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:
References
For how to output encode properly, read the new Site Scripting) Prevention Cheat Sheet

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> )
#4: All non-alphanumeric < 256  \HH
ESAPI: encodeForCSS()
CSS Style Property Values
(e.g., .pdiv a:hover {color: red; text-decoration: underline} )
#5: All non-alphanumeric < 256  %HH
ESAPI: encodeForURL()
URI Attribute Values
(e.g., <a href="javascript:toggle('lesson')" )
Recommendation: Only allow #1 and #2 and disallow all others
See: for more details

15. A3 – Broken Authentication and Session Management
Means credentials have to go with every request
Should use SSL for everything requiring authentication
HTTP is a “stateless” protocol
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, …
Session management flaws
Change my password, remember my password, forgot my password, secret question, logout, address, etc…
Beware the side-doors
User accounts compromised or user sessions hijacked
Typical Impact

16. A3 – Broken Authentication Illustrated1
User sends credentials
Custom Code
Accounts
Finance
Administration
Transactions
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions
Site uses URL rewriting
(i.e., put session in URL) 2 3
User clicks on a link to in a forum
Hacker checks referer logs on
and finds user’s JSESSIONID 4 5
Hacker uses JSESSIONID and takes over victim’s account

17. A3 – Avoiding Broken Authentication and Session Management
Verify your architecture
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
Verify the implementation
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

18. +JS
NEXT
JScrambler

19. Who we are ? The Start Vision/Mission The Company
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
The Start
Vision: we believe that the strongest approach to Web Security should be to put the 1st line of defense on the client-side
Mission: to be a leader in Web Application Protection technology
Vision/Mission
Top Web Security Team
30Y of combined experience
Being advised by Pereira Ventures in its International Expansion
The Company
Leaders in JavaScript
Obfuscation since 2010
Top 100 European Startup in 2009
In the European Unlimited Eurecan European Contest
Awards

20. What do we do? Web Traffic Security Services Auditing Web
JavaScript Source code protection Obfuscates JS/HTML5 WebApps
Protects the code from being stolen, inspected, tampered with
Web
Traffic
Auditing
Security Services
Enterprise Web Application Protection against Man int the Browser and other security attacks
Web
Application Security

21. What is the world’s most popular language ?

22. 3+ Years Protecting Apps
Release History
+3 YEARS PROTECTING WEB APPLICATIONS
Beta version
1.0 released
2.0 released
3.0 released
JS lines of code
120
MILLION PROTECTED
106
Countries
5000
Clients

23. JScrambler Feedback ROVIO TECHCRUNCH RSA SECURITY Customer NEWS
“JScrambler does seem to offer the most complete solution. Out of the box, it should work with most of the standard libraries”
TECHCRUNCH
Customer
“JScrambler results look promising”
ROVIO
Customer
"We are trying to push the envelope and it’s good to have a nimble partner that is aggressive at achieving this”
RSA SECURITY

24. JScrambler Obfuscation Code Execution Control Optimization
State of the art Web Application Protection and Optimization
JavaScript
HTML5/JavaScript
Mobile Web Applications
Web Games
Obfuscation
JavaScript
Domain Lock
Expiration Date
Anti-debugging
Code Execution Control
JavaScript
Code Simplification
Dead Code Removal
Compression
Optimization

25. JScrambler
Obfuscation: The art of making code unreadable

26. JScrambler Domain Lock Expiration Date Anti Debugging
Code Execution Control
Domain Lock
Expiration Date
Anti Debugging

27. JavaScript Obfuscation
NEXT
JavaScript Obfuscation

28. NEXT
We look forward for you contact and feedback
Questions

29. Contact Us Porto Headquarters Lisbon Office Pedro Fortuna CTO
Edifício Central da UPTEC
Rua Alfredo Allen, 455
Porto, Portugal
Lisbon
Office
Rua da Prata 121 5º A Lisboa Portugal
Pedro Fortuna
CTO
auditmark.com