Hackers versus Developers and Secure Web Programming

HACKERS VS
DEVELOPERS
Fighting the good fight

HACKER

is one who doesn‟t
play by your rules

HACKER

is one who will gain from making
your app respond in a manner
that you didn’t anticipate

DEVELOPER

is one who creates a
system ; wants the
system to run as
expected

DEVELOPER

almost always doesn‟t think about
attacking the app from the point of
view of someone who wants to
exploit – the app, the resources
supporting the app or the data

FIGHTING THE GOOD FIGHT

hackers need only one opening,
one weakness.
developers need to constantly
ensure that the security and the
integrity of the application is
maintained

RA.ONE VERSUS G.ONE

developers will defend and the
hackers will attack
the good fight is about making
secure apps, keeping them
secure in operation and
safeguarding user data

HACKERS ARE NECESSARY AND NOT
EVIL

hackers and developers
represent duality. Without
pesky hackers developers
mayn‟t have the incentive to
keep making secure
applications.

SOMETHING TO THINK ABOUT
 95% of attacks are against “Web Servers and Web
Applications” aka Websites
 The top 3 verticals compromised were Financial
Services, Hospitality and Retail.
 More than 60% of attacks were caused by external
agents.
 Primary attack vector was SQL Injection and was used
to install customized malware.
 Injection Attacks are #1 critical flaw in applications

Sources Verizon DBIR 2010, Whitehat Sec Statistics, OWASP Top 10
2010

WEB APP ARCHITECTURE – 3
TIER
USER AGENTS
WEB SERVERS
User Agent / Client. Browser, BOT,
Program Sends Requests like GET, Web Server listens for requests and sends
POST, HEAD, PUT, DELETE appropriate responses like 200, 404, 403
•Has the programming logic to understand
all types of requests ( PHP/ASP.net)
•Talks to the database

Database Software
System MySQL, MSSQL

W EB SECURITY TRAINING © AKASH
MA H A J A N 1 7 T H - 1 9 T H MA Y 2 0 1 0 13

WEB APP ARCHITECTURE DATA VIEW

Trusted
Web Data Store
Code
Client Running on
server
Web Server

Un-trusted Input
hitting the server
Web
from the client,
Service
data stores, web
services.

WEB APP ARCHITECTURE – DATA VIEW

The only piece we can trust is the code
running on the server.
Any data coming to the server, regardless
of where it originated from shouldn‟t be
trusted.
Data should only be trusted once it has
been validated by some piece of trusted
code.

WEB APP ARCHITECTURE – DATA VIEW

Trusted code is the code which we know
for sure is the same thing that was
developed and the integrity is
maintained.
Based on the validation we can classify
data as tainted/bad or un-tainted/good.
Only after that the data which is good
data for the application should be
processed.

WHERE ALL IS THE DATA COMING
FROM?
GET Requests
POST Requests, HTML Form data
Cookies stored
HTTP Headers
File Uploads
RSS feeds
External data-stores or web services

@ MA K A S H | A K A S H M. C O M | T H A T W E B
APPLICATION SECURITY GUY

DATA FLOWS

Four main data flows in any web
application
 Data from request going to be displayed in the
browser
 Data from the request going to be stored in the
database
 Data from the response ( from the database ) going
to be displayed in the browser
 Data from request going to call a remote
method/API or read/write something on the server

DATA YOU CAN‟T TRUST
 Good data for a login page
 Username – foo
 Password – bar
 Bad data for a login page
 Username – foo‟ OR 1=1;--
 Password – bar‟ OR 1=1;--
 Good data for a comment
 This is a nice comment
 Bad data for a comment
 This is an XSS</textarea><script>alert(document.cookie);</script>

@ MA K A S H | A K A S H M. C O M - T H A T W E B

DATA YOU NEED TO PROTECT

 Clear text passwords for a username
email@example.com
 Password is 123456
 Data thief steals the entire database and has reusable
account details
 http://somebank.cxm/account-details.php?id=1234
 Did you check that only user with id 1234 can see this?
 What if the attacker stole the session cookie of user
with id 1234

@ MA K A S H | A K A S H M. C O M - T H A T W E B

WHAT IS THE RISK?

Data view of the web app
shows two places of attack
Attacking the web application
Attacking the users of the said
web application

TYPES OF ATTACKS

 All these attack the web application hosted and
running on the web server
 Injection attacks
 SQL Injection – attacking the database
 Command Injection – attacking the system

 File Inclusion attacks
 Local File Inclusion
 Remote File Inclusion

 HTTP Response Splitting – attacking HTTP


ATTACKING THE WEB APP USER

All these attacks are meant to attack the user
of the web application through it.
Cross Site Scripting or commonly known as
XSS
Cross Site Request Forgery also called Sea-
Surf
Broken Authentication and Sessions
Management


WHY SHOULD WE MAKE SECURE WEB
APPS
Malicious users, automated programs,
ignorant users are all trying to break your
web application as we speak.
Web applications which get hacked, go
down or fail while being used bring
disrepute to your company, can attract
financial damages and can be used to
attack other targets on the web.

HOW DO WE MAKE SECURE WEB
APPS
Always do server side validation.
Any and every data point that originates from
outside your web application is bad unless
proved otherwise.
GET, POST, COOKIE, FILES all requests are
bad.
So we need to ensure only trusted good data
is processed, is allowed in the database and is
rendered by the browser.

INTEGRITY OF A WEB
APPLICATION
As the developer you need to ensure that your
web application has integrity. The data that
flows through it is known, can be trusted and
improper data is dealt with in a known way.
You can do with error handlers, exception
handling and failing gracefully.
If you look at it holistically the entire point of
your web app is to shovel data from one point
to another and do cool things with it.

CROSS SITE SCRIPTING - XSS

Injecting HTML/JS into the site.
 Non-persistent/Reflected/First Order
 Script is taken from the request and displayed in the
browser directly
 example.com/search?q=<script>alert(„hi‟);</script>

 Persistent/Stored/Second Order
 First name of a registration form is vuln and the value is
stored in the database
 Hello <iframe src=http://f1y.in/0.js></iframe>

XSS MITIGATION IN ASP.NET 2.0
 Constrain input and Encode output
 For inputs through server controls use validate controls like
 RegularExpressionValidator
 RangeValidator
 For inputs from query strings, cookies, client side HTML
 System.Text.RegularExpressions.Regex class
 Encode output for html. Convert < to < “ to "
 HttpUtility.HtmlEncode
 Response.Write(HttpUtility.HtmlEncode(Request.Form[“foo"]));
 Encode output for urls created from user input

XSS MITIGATION IN ASP.NET 2.0
 HttpUtility.UrlEncode
 Response.Write(HttpUtility.UrlEncode(urlString));

 Check that request validation is enabled in Machine.config and is
not overwritten by the Web.config
 <system.web> <pages buffer="true" validateRequest="true" /> </system.web>
 You can set it to false for certain pages which might require rich text
processing.
 Client headers like user agent can be malicious as well.
 Thumb rule, if its not your data consider it bad. If you can verify it,
consider it trusted good data.
 White listing helps in verifying good data more than black listing.
 See examples at xssed.com
 Try out MS Anti XSS Library http://www.codeplex.com/AntiXSS

XSS MITIGATION IN PHP
 Sanitize all globals ($_GET, $_POST, $_COOKIE)
 Use strip_tags()
 Use inpekt library code.google.com/p/inspekt
 Escape everything before displaying
 htmlentities(), htmlspeciachars()
 Client headers like user agent can be malicious as well.
 Thumb rule, if its not your data consider it bad. If you can verify it,
consider it trusted good data.
 White listing helps in verifying good data more than black listing.
 See examples at xssed.com

SQL INJECTION

 Allowing SQL to be injected in the database query.
 Most common attack point is the search of any
dynamic website and registration forms. These two will
be definitely talking to the database.
 $sql =

SQL INJECTION - MITIGATION
myCommand.SelectCommand.Parameters.Add("@name", SqlDbType.VarChar, 40);
myCommand.SelectCommand.Parameters["@name"].Value =
Request.QueryString[„name‟];
myCommand.Fill(userDataset);
}
 Avoid disclosing database error information
 <customErrors mode="remoteOnly" />
 <customErrors mode="On" defaultRedirect=“ErrorPage.htm" />

 See a kickass example of stored proc used to hack more than hundred
thousand websites
 http://www.breach.com/resources/breach-security-labs/alerts/mass-sql-injection-attack-
evolution
 MS Source Code Analyzer to SQL Injection
 http://www.microsoft.com/downloads/details.aspx?familyid=58A7C46E-A599-4FCB-
9AB4-A4334146B6BA&displaylang=en

SQL INJECTION - MITIGATION
 mysql_real_escape_string()
 $dbquery = sprintf(“SELECT name FROM user WHERE id=„%s‟”,
mysql_real_escape_string(„id‟));
 Parameterized queries
 $res = $query(“SELECT name FROM user WHERE id=?”, $id);
 Standard mysql module in PHP doesn‟t allow for parameterized queries. You
need mysqli
 Stored Procedures
 See a kickass example of stored proc used to hack more than hundred
thousand websites
 http://www.breach.com/resources/breach-security-labs/alerts/mass-sql-injection-
attack-evolutio

Hackers versus Developers and Secure Web Programming

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Hackers versus Developers and Secure Web Programming (20)

More from Akash Mahajan (16)

Recently uploaded (20)

Hackers versus Developers and Secure Web Programming