Hackers versus Developers and Secure Web Programming

2,490 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,490
On SlideShare
0
From Embeds
0
Number of Embeds
22
Actions
Shares
0
Downloads
45
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Hackers versus Developers and Secure Web Programming

  1. 1. HACKERS VSDEVELOPERSFighting the good fight
  2. 2. HACKERis one who doesn‟tplay by your rules
  3. 3. HACKERis one who will gain from makingyour app respond in a mannerthat you didn’t anticipate
  4. 4. DEVELOPERis one who creates asystem ; wants thesystem to run asexpected
  5. 5. DEVELOPERalmost always doesn‟t think aboutattacking the app from the point ofview of someone who wants toexploit – the app, the resourcessupporting the app or the data
  6. 6. hackersalways win
  7. 7. so why bother fighting?
  8. 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. 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. 10. HACKERS ARE NECESSARY AND NOTEVILhackers and developersrepresent duality. Withoutpesky hackers developersmayn‟t have the incentive tokeep making secureapplications.
  11. 11. SECURE WEBPROGRAMMING
  12. 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
  13. 13. WEB APP ARCHITECTURE – 3TIER 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, MSSQLW EB SECURITY TRAINING © AKASHMA H A J A N 1 7 T H - 1 9 T H MA Y 2 0 1 0 13
  14. 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. 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. 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. 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 BAPPLICATION SECURITY GUY
  18. 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. 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 BAPPLICATION SECURITY GUY
  20. 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 BAPPLICATION SECURITY GUY
  21. 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. 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 BAPPLICATION SECURITY GUY
  23. 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 BAPPLICATION SECURITY GUY
  24. 24. WHY SHOULD WE MAKE SECURE WEBAPPS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. 25. HOW DO WE MAKE SECURE WEBAPPS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. 26. INTEGRITY OF A WEBAPPLICATION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. 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. 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 &lt; “ to &quot;  HttpUtility.HtmlEncode  Response.Write(HttpUtility.HtmlEncode(Request.Form[“foo"])); Encode output for urls created from user input
  29. 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. 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. 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. 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. 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. 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

×