5. 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
8. 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
9. 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
10. 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.
12. 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
14. 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.
15. 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.
16. 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.
17. 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
18. 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
19. 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
APPLICATION SECURITY GUY
20. 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
APPLICATION SECURITY GUY
21. 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
22. 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
@ MA K A S H | A K A S H M. C O M | T H A T W E B
APPLICATION SECURITY GUY
23. 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
@ MA K A S H | A K A S H M. C O M | T H A T W E B
APPLICATION SECURITY GUY
24. 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.
25. 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.
26. 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.
27. 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>
28. 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
29. 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
30. 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
31. 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 = "SELECT * FROM table WHERE id = '" .
Request.QueryString[„id‟] . "'";
id = ' ; DROP DATABASE pubs –
Excellent examples
http://google.com/search?q=site:slideshare.net sql
injection
32. SQL INJECTION - MITIGATION
Sanitize input data. Check for lengths & types
Use type safe SQL parameterized queries for stored procedures
or dynamic SQL queries
Parameter collection SqlParameterCollection
using (SqlConnection connection = new SqlConnection(connectionString))
{
DataSet userDataset = new DataSet();
SqlDataAdapter myCommand = new SqlDataAdapter(
"LoginStoredProcedure", connection);
myCommand.SelectCommand.CommandType =
CommandType.StoredProcedure;
33. 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
34. 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