1. Copyright Security-Assessment.com 2005 Secure Coding Practice

2. Copyright Security-Assessment.com 2005 Why Secure Code Is so Important

3. Copyright Security-Assessment.com 2005 Web Application Vulnerability Statistics Qualys last 200 Checks – Web App: 40 (20%) XSS: 9 SQL Injection: 6 OS Injection: 5 Secunia October Advisories (73 total) – Web App: 14 (19%) XSS: 4 SQL injection: 3 SecurityFocus October Vulnerabilties (150 total) – Web App: 35 (23%) XSS: 10 SQL Injection: 10 OS injection: 3

4. Copyright Security-Assessment.com 2005 Statistics Continued Those statistics were only with Off-the-shelf web applications Custom web applications tend to contain many more vulnerabilities Very rare to find an application without at least one major web application vulnerability 95% of applications tested contain an XSS vulnerability

5. Copyright Security-Assessment.com 2005 Source Review vs Penetration Test Penetration Test – Pros Simulates real-world attack Can be performed relatively quickly – Cons Will never find all vulnerabilities Only tests outer layer Must be performed once the system is ready

6. Copyright Security-Assessment.com 2005 Source Review vs Penetration Test Source Code Review – Pros Ability to review all code Finds vulnerabilities hidden inside conditional flows Can be performed earlier in the project to catch vulnerabilities as soon as possible – Cons Time consuming Does not simulate a real-world attack

7. Copyright Security-Assessment.com 2005 Security In The SDLC The Longer a security vulnerability is left unsolved, the more costly to resolve Security should therefore be built into the SDLC to catch vulnerabilities as soon as possible It is too late to wait until one week before go-live to get a security review performed

8. Copyright Security-Assessment.com 2005 Standard SDLC Requirements Architecture/Design Development Integration Testing Deployment Maintenance

9. Copyright Security-Assessment.com 2005 How Security Fits Into The SDLC Requirements – Initial risk assessment – Make security requirements explicit – Threat modelling during use cases Architecture/Design – Design security review Development – Application development standards – Iterative code reviews – Automated code testing

10. Copyright Security-Assessment.com 2005 How Security Fits Into The SDLC Integration Testing – Application penetration testing – Automated scanning Deployment – Traditional go-live testing Maintenance – Regression testing – Code reviews of changes – Operational procedure reviews

11. Copyright Security-Assessment.com 2005 Why A Coding Policy Is Important Developers are not security experts so need advice on how to code securely Developers change over time Outsourcing give little control over developers – A coding policy can help ensure security is at an adequate level – Make software acceptance dependant on compliance with the coding policy Security techniques change over time

12. Copyright Security-Assessment.com 2005 Introduction To Common Vulnerabilities - XSS

13. Copyright Security-Assessment.com 2005 What Is XSS? XSS stands for Cross-Site Scripting It is the ability of one person to inject HTML code into another person’s session Generally comes in two forms: – Reflective (code stored in a URL, requires tricking a user to click on the URL) – Storage-based (code stored on the site, often does not require user interaction)

14. Copyright Security-Assessment.com 2005 Why Is It Bad? XSS allows an attacker to manipulate the HTML of a web page. Typical exploits include: – Page modification (defacement) – Redirection (for example login forms) – Site interaction on behalf of user (AJAX) – Pretty much anything you can do with JavaScript

15. Copyright Security-Assessment.com 2005 Some Myths About XSS XSS isn’t a real threat, it can’t do any real damage WRONG – XSS can lead to a serious compromise of either the site or the victim Examples – XSS-based worms – Myspace.com example – AJAX – Imagine an Internet Banking site where an XSS attack automatically checks your balance then transfers the maximum to an attacker’s account

16. Copyright Security-Assessment.com 2005 XSS Myths Continued An attacker has to trick a user into following a malicious link WRONG – Storage-based XSS Examples – XSS in registration page to compromise Admin – XSS in profile pages – XSS in messages/forums/bulletin boards

17. Copyright Security-Assessment.com 2005 XSS Myths Continued I use post for all my input therefore I am safe from XSS WRONG – an attacker can craft a page that POSTS to your site to cause XSS Example –

18. Copyright Security-Assessment.com 2005 XSS Myths Continued I filter so I am safe WRONG – Some types of XSS do not require Examples – " "onmouseover= "alert('XSS'); – +ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-

19. Copyright Security-Assessment.com 2005 Issues With Common Methods To Detect XSS Common detection methods tend to rely on recognising dangerous characters There is such a large variation in how these exploits can occur that detection is often difficult Even vendors get it wrong: –.Net XSS filter bypass – foo.bar/test.asp?term= alert(‘XSS')

20. Copyright Security-Assessment.com 2005 Multiple variations of XSS alert('XSS') +ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4- " "onmouseover= "alert('XSS');

21. Copyright Security-Assessment.com 2005 How To Defend Against XSS Only allow known good input – Numeric fields – Boolean fields – Alpha fields – AlphaNumeric fields – Length checked If Special characters must be allowed, do not allow the following characters: – “ ' & + ; # / \ % Always encode output as well as filtering input

22. Copyright Security-Assessment.com 2005 Introduction To Common Vulnerabilities – SQL Injection

23. Copyright Security-Assessment.com 2005 What Is SQL Injection? Ability to execute unauthorised SQL statements by manipulating user input – SQLquery = “SELECT * FROM users WHERE username = ‘” + user + “' AND password = ‘” + password + “';” – http://www.target.com/login.asp?user=admin&password=' %20OR%20'1'='1 – Query becomes “SELECT * FROM users WHERE username = 'admin' AND password = '' OR '1' = '1';”

24. Copyright Security-Assessment.com 2005 Some Myths About SQL Stored Procedures Protects Against SQL WRONG – Stored procedures can use inputs to build a statement and then execute Example CREATE PROCEDURE MyProc (@TableName varchar(255), @FirstName varchar(50), @LastName varchar(50)) AS DECLARE @SQLStatement varchar(255) SELECT @SQLStatement = "SELECT * FROM " + @TableName + "WHERE FirstName = '" + @FirstName + "' AND LastName = '" + @LastName + "'" EXEC(@SQLStatement)

25. Copyright Security-Assessment.com 2005 SQL Myths Continued I Filter the ' character so I am safe from SQL WRONG – if you have SQL that expects numeric, an attack does not need ' Example – “SELECT * FROM table WHERE int = @userinput;” – The attack can look like following: 1 or 1=1 – or 1; insert into users values( 666, char(0x63)+char(0x68)+char(0x72)+char(0x69)+char(0x73), char(0x63)+char(0x68)+char(0x72)+char(0x69)+char(0x73), 0xffff)

26. Copyright Security-Assessment.com 2005 Common SQL Injection Variations Standard - Using ' to close string – /vuln.asp?string=' Password Circumvention – /login.asp?user=admin&password='or'1'='1 Comment Injection – /login.asp?user=admin';--&password=whocares SubSelects – /vuln.asp?string=' + (SELECT TOP 1 FieldName FROM TableName) + '

27. Copyright Security-Assessment.com 2005 SQL Injection Variations Continued Table Enumeration With UNION – /vuln.asp?string=' UNION ALL SELECT name,9,'a' FROM sysobjects where xtype='U Statement Concatenation – /vuln.asp?string='; INSERT INTO adminusers (username,password) VALUES ('hacked', 'p0wn3d');-- Command Execution – /vuln.asp?string=';EXEC master.dbo.xp_cmdshell 'cmd.exe dir c:

28. Copyright Security-Assessment.com 2005 SQL Injection Variations Continued Numeric Attack – /vuln.asp?int=1 or 1=1 Numeric Insertion – /vuln.asp?int=1; insert into users values( 666, char(0x63)+char(0x68)+char(0x72)+char(0x69)+char(0x7 3), char(0x63)+char(0x68)+char(0x72)+char(0x69)+char(0x7 3), 0xffff) Using Tab To Bypass Space Checks – /vuln.asp?string=‘%90+%90(SELECT%90TOP%901%90Fie ldName%90FROM%90TableName)%90+%90'

29. Copyright Security-Assessment.com 2005 How To Defend Against SQL Injection Only allow known good input – Numeric fields – Boolean fields – Alpha fields – AlphaNumeric fields – Length checked If Special characters must be allowed, do not allow the following characters: – “ ' & + ; # / \ % {whitespace}

30. Copyright Security-Assessment.com 2005 SQL Injection Defence Continued Only use parameterised stored procedures Never generate SQL statements on the fly using strings Restrict the user account accessing the database – Only allow the user access to the specific stored procedures required – Remove access to master stored procedures (xp_cmdshell etc)

31. Copyright Security-Assessment.com 2005 Why Whitelist Beats Blacklist As can be seen from the examples today, it is very difficult to know and block all variations of attacks Therefore, using a blacklist to search for known bad data is risky Best strategy is to know what data is expected and make sure this is true Make your checks are as specific as possible: – Type of characters allowed – Length

32. Copyright Security-Assessment.com 2005 Keep It Secure

33. Copyright Security-Assessment.com 2005 Continued Testing Any changes to the code can introduce new security vulnerabilities All code changes should be checked to ensure they: – Comply with the coding policy – Do not introduce new security vulnerabilities Security changes over time, what was secure today may not be secure in a year’s time Make sure security tests are performed on a regular basis

34. Copyright Security-Assessment.com 2005 Protect The Source It is not enough to review one version of code Must ensure that the ability to insert malicious code is minimised Must ensure that access to source code is restricted (CISCO)

35. Copyright Security-Assessment.com 2005 Testing Tools Source Code Analysis – CodeScan (of course ) – PMD – Findbugs Automated Web Application Testing Tools – WebInspect – AppScan – AppDetective – ScanDo

36. Copyright Security-Assessment.com 2005 References Open Web Application Security Project http://www.owasp.org XSS Cheatsheet http://ha.ckers.org/xss.html Codescan Source code analysis Tool http://www.codescan.com

37. Copyright Security-Assessment.com 2005 Questions?