1.HACKERS VSDEVELOPERSFighting the good fight

2. HACKERis one who doesntplay by your rules 3. HACKERis one who will gain from makingyour app respond in a mannerthat you didnt anticipate 4. DEVELOPERis one who creates asystem ; wants thesystem to run asexpected 5. DEVELOPERalmost always doesnt think aboutattacking the app from the point ofview of someone who wants toexploit the app, the resourcessupporting the app or the data 6. hackersalwayswin 7. so why bother fighting? 8. FIGHTING THE GOOD FIGHThackers 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.ONEdevelopers will defend and the hackers will attackthe good fight is about making secure apps, keeping them secure in operation and safeguarding user data 10. HACKERS ARE NECESSARY AND NOTEVILhackers and developersrepresent duality. Withoutpesky hackers developersmaynt have the incentive tokeep making secureapplications. 11. SECURE WEBPROGRAMMING 12. SOMETHING TO THINK ABOUT 95% of attacks are against Web Servers and WebApplications aka Websites The top 3 verticals compromised were FinancialServices, Hospitality and Retail. More than 60% of attacks were caused by externalagents. Primary attack vector was SQL Injection and was usedto install customized malware. Injection Attacks are #1 critical flaw in applicationsSources Verizon DBIR 2010, Whitehat Sec Statistics, OWASP Top 10 2010 13. WEB APP ARCHITECTURE 3TIERUSER AGENTS WEB SERVERSUser Agent / Client. Browser, BOT,Program Sends Requests like GET, Web Server listens for requests and sendsPOST, HEAD, PUT, DELETEappropriate responses like 200, 404, 403 Has the programming logic to understand all types of requests ( PHP/ASP.net) Talks to the databaseDatabase SoftwareSystem MySQL, MSSQLW EB SECURITY TRAINING AKASHMA H A J A N1 7 T H - 1 9 T H MA Y 2 0 1 0 13 14. WEB APP ARCHITECTURE DATA VIEW Trusted Web Data StoreCode Client Running onserverWeb Server Un-trusted Input hitting the server Web from the client,Service data stores, web services. 15. WEB APP ARCHITECTURE DATA VIEWThe only piece we can trust is the code running on the server.Any data coming to the server, regardless of where it originated from shouldnt be trusted.Data should only be trusted once it has been validated by some piece of trusted code. 16. WEB APP ARCHITECTURE DATA VIEWTrusted 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 COMINGFROM? 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. DATA FLOWSFour main data flows in any web application Data from request going to be displayed in thebrowser Data from the request going to be stored in thedatabase Data from the response ( from the database ) goingto be displayed in the browser Data from request going to call a remotemethod/API or read/write something on the server 19. DATA YOU CANT 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@ MA K A S H | A K A S H M. C O M - T H A T W E BAPPLICATION 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 BAPPLICATION 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 saidweb 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 BAPPLICATION SECURITY GUY 23. ATTACKING THE WEB APP USER All these attacks are meant to attack the userof the web application through it. Cross Site Scripting or commonly known asXSS Cross Site Request Forgery also called Sea-Surf Broken Authentication and SessionsManagement@ MA K A S H | A K A S H M. C O M | T H A T W E BAPPLICATION SECURITY GUY 24. WHY SHOULD WE MAKE SECURE WEBAPPSMalicious 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 WEBAPPSAlways 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 WEBAPPLICATIONAs 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 - XSSInjecting HTML/JS into the site. Non-persistent/Reflected/First Order Script is taken from the request and displayed in thebrowser directly example.com/search?q= Persistent/Stored/Second Order First name of a registration form is vuln and the value isstored in the database Hello 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 isnot overwritten by the Web.config You can set it to false for certain pages which might require rich textprocessing. 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 anydynamic website and registration forms. These two willbe definitely talking to the database. $sql = "SELECT * FROM table WHERE id = " .Request.QueryString[id] . ""; id =; DROP DATABASE pubs Excellent exampleshttp://google.com/search?q=site:slideshare.net sqlinjection 32. SQL INJECTION - MITIGATION Sanitize input data. Check for lengths & types Use type safe SQL parameterized queries for stored proceduresor 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 - MITIGATIONmyCommand.SelectCommand.Parameters.Add("@name", SqlDbType.VarChar, 40);myCommand.SelectCommand.Parameters["@name"].Value = Request.QueryString[name];myCommand.Fill(userDataset);} Avoid disclosing database error information See a kickass example of stored proc used to hack more than hundredthousand 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 doesnt 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