Application Security and Secure Programming

8/11/2019 Application Security and Secure Programming

1/81

bySemi YuliantoMCT, CEH, ECSA, CHFI, ECSP, SSCP, CISSP, CASP, CISA


2/81

Part I

Secure Programming

Securing Engineering

Web Application Attacks

Web App Security Statistics

OWASP Top 10

Security Development Lifecycle

SDL Optimization Model SDL Security Activities

SDL Process Illustration


3/81

Part II

Security Concern in Development

Tools Used by Organization in SDL

Activities Uses in SDL Security Training for Developers

Results of Implementing SDL

Dos and Donts

Best Practices


4/81


Practical OWASP Top 10

Application Vulnerability Assessment

Web Application Pen-Testing Using SDL Tools

Threat Modeling

Code Review

Challenge Exercises


5/81

PART I


6/81

Secure Programming is the practice of developingsoftware where attention and planning is given toproducing robust and reliable applications that operatesecurely.

Secure Programming presents practical programmingtechniques for developing and enhancing the security ofapplications.

Primary methods of attacks and perpetrators aresurveyed and concrete recommendations are given toprevent each type of attack.


7/81

Primary methods of attacks and perpetrators aresurveyed and concrete recommendations are given toprevent each type of attack.

Secure development concepts, techniques and goals areidentified.

A list of secure programming dos and donts included.

Guideline for both testing software and code reviews arepresented.


8/81

Common Questions Asks

How can an organization build secure programming

into application development process?

Failure to define clear and detailed securityrequirements is one of the most common issues in

the security assurance process.


9/81


How can automated code analysis tools aid in

setting secure programming standards?

Default secure programming standards can beadopted as a by-product of implementing an

automated code analysis tool.


10/81


Are development teams ultimately responsible for

insecure software?

The default responsibility for preventing securityvulnerabilities in source code often falls to the

development organization.


11/81

Securing Engineering presents an overview of key

security engineering activities that should be an

integral part of your application development

lifecycle.

Key Objective is to include specific security-related

activities in your current software engineering

processes.


12/81

Securing Engineering activities includes:

Identifying security objectives.

Applying secure design guidelines, patterns and principles.

Creating threat models.

Conducting architecture and design reviews for security.

Performing regular code reviews for security.

Testing for security.

Conducting development reviews to ensure secure

configuration.


13/81


14/81


15/81


16/81


17/81


18/81


19/81


20/81


21/81

Attacks Abuse of Functionality

Brute Force

Buffer Overflow

Content Spoofing Credential/Session Prediction

Cross-Site Scripting

Cross-Site Request Forgery

Denial of Service Fingerprinting

Format String


22/81

Attacks HTTP Response Smuggling HTTP Response Splitting HTTP Request Smuggling HTTP Request Splitting Integer Overflows LDAP Injection Mail Command Injection Null Byte Injection OS Commanding Path Traversal Predictable Resource Location Remote File Inclusion (RFI)


23/81

Attacks Routing Detour Session Fixation SOAP Array Abuse SSI Injection SQL Injection URL Redirector Abuse XPath Injection XML Attribute Blowup XML External Entities XML Entity Expansion XML Injection XQuery Injection


24/81

Weaknesses

Application Misconfiguration

Directory Indexing

Improper Filesystem Permissions Improper Input Handling

Improper Output Handling

Information Leakage

Insecure Indexing


25/81

Weaknesses

Insufficient Anti-automation

Insufficient Authentication

Insufficient Authorization Insufficient Password Recovery

Insufficient Process Validation

Insufficient Session Expiration

Insufficient Transport Layer Protection

Server Misconfiguration


26/81

Real Life Attack Examples:

WHID 2010-68: Daily Telegraph website hacked

Occurred:April 15, 2010

Attack Method: Unknown

Application Weakness:

Outcome: Defacement

Reference:

http://www.guardian.co.uk/media/2010/apr/15/daily-

telegraph-hacking
http://www.guardian.co.uk/media/2010/apr/15/daily-telegraph-hackinghttp://www.guardian.co.uk/media/2010/apr/15/daily-telegraph-hackinghttp://www.guardian.co.uk/media/2010/apr/15/daily-telegraph-hackinghttp://www.guardian.co.uk/media/2010/apr/15/daily-telegraph-hackinghttp://www.guardian.co.uk/media/2010/apr/15/daily-telegraph-hackinghttp://www.guardian.co.uk/media/2010/apr/15/daily-telegraph-hackinghttp://www.guardian.co.uk/media/2010/apr/15/daily-telegraph-hacking


27/81


28/81


WHID 2010-67: Apache.org hit by targeted XSS

attack, passwords compromised


Attack Method: Brute Force, Cross Site Scripting (XSS)

Application Weakness: Improper Output Handling

Outcome: Session Hijacking

Reference:

http://blogs.zdnet.com/security/?p=6123&tag=nl.e539
http://blogs.zdnet.com/security/?p=6123&tag=nl.e539http://blogs.zdnet.com/security/?p=6123&tag=nl.e539


29/81


WHID 2010-66: Ads to blame for malware in

Facebook's FarmTown?


Attack Method: Malvertising

Application Weakness: Improper Output Handling

Outcome: Planting of Malware

Reference: http://news.cnet.com/8301-27080_3-

20002267-245.html
http://news.cnet.com/8301-27080_3-20002267-245.htmlhttp://news.cnet.com/8301-27080_3-20002267-245.htmlhttp://news.cnet.com/8301-27080_3-20002267-245.htmlhttp://news.cnet.com/8301-27080_3-20002267-245.htmlhttp://news.cnet.com/8301-27080_3-20002267-245.htmlhttp://news.cnet.com/8301-27080_3-20002267-245.htmlhttp://news.cnet.com/8301-27080_3-20002267-245.htmlhttp://news.cnet.com/8301-27080_3-20002267-245.htmlhttp://news.cnet.com/8301-27080_3-20002267-245.html


30/81

References:

http://projects.webappsec.org/Threat-

Classification

http://projects.webappsec.org/Threat-Classification-Enumeration-View

http://projects.webappsec.org/Web-Hacking-

Incident-Database
http://projects.webappsec.org/Threat-Classificationhttp://projects.webappsec.org/Threat-Classificationhttp://projects.webappsec.org/Threat-Classification-Enumeration-Viewhttp://projects.webappsec.org/Threat-Classification-Enumeration-Viewhttp://projects.webappsec.org/Web-Hacking-Incident-Databasehttp://projects.webappsec.org/Web-Hacking-Incident-Databasehttp://projects.webappsec.org/Web-Hacking-Incident-Databasehttp://projects.webappsec.org/Web-Hacking-Incident-Databasehttp://projects.webappsec.org/Web-Hacking-Incident-Databasehttp://projects.webappsec.org/Web-Hacking-Incident-Databasehttp://projects.webappsec.org/Web-Hacking-Incident-Databasehttp://projects.webappsec.org/Web-Hacking-Incident-Databasehttp://projects.webappsec.org/Web-Hacking-Incident-Databasehttp://projects.webappsec.org/Threat-Classification-Enumeration-Viewhttp://projects.webappsec.org/Threat-Classification-Enumeration-Viewhttp://projects.webappsec.org/Threat-Classification-Enumeration-Viewhttp://projects.webappsec.org/Threat-Classification-Enumeration-Viewhttp://projects.webappsec.org/Threat-Classification-Enumeration-Viewhttp://projects.webappsec.org/Threat-Classification-Enumeration-Viewhttp://projects.webappsec.org/Threat-Classification-Enumeration-Viewhttp://projects.webappsec.org/Threat-Classificationhttp://projects.webappsec.org/Threat-Classificationhttp://projects.webappsec.org/Threat-Classification


31/81

LIVE DEMO



32/81

Probability to detect vulnerabilities depending on their origin


33/81

The most widespread vulnerabilities in web applications


34/81



35/81



36/81

The distribution of websites not compliant to PCI DSS


37/81

The distribution of websites not compliant to PCI DSS


38/81


39/81


40/81


41/81


42/81


43/81


44/81


45/81


46/81

The primary aim of the OWASP Top 10 is to educatedevelopers, designers, architects, and organizations

about the consequences of the most common web

application security vulnerabilities.

The Top 10 provides basic methods to protect

against these vulnerabilities a great start to your

secure coding security program.


47/81

A01 Cross-site ScriptingXSS flaws occur whenever an application takes user supplieddata and sends it to a web browser without first validating orencoding that content. XSS allows attackers to execute scriptin the victim's browser which can hijack user sessions, deface

web sites, possibly introduce worms, etc.

A02 Injection Flaws

Injection flaws, particularly SQL injection, are common inweb applications. Injection occurs when user-supplied data issent to an interpreter as part of a command or query. Theattacker's hostile data tricks the interpreter into executingunintended commands or changing data.


48/81

A03 Malicious File ExecutionCode vulnerable to remote file inclusion (RFI) allowsattackers to include hostile code and data, resulting indevastating attacks, such as total server compromise.Malicious file execution attacks affect PHP, XML and any

framework which accepts filenames or files from users.

A04 Insecure Direct Object Reference

A direct object reference occurs when a developer exposes areference to an internal implementation object, such as a file,directory, database record, or key, as a URL or formparameter. Attackers can manipulate those references toaccess other objects without authorization.


49/81

A05 Cross-site Request Forgery (CSRF)A CSRF attack forces a logged-on victim's browser to send apre-authenticated request to a vulnerable web application,which then forces the victim's browser to perform a hostileaction to the benefit of the attacker. CSRF can be as powerful

as the web application that it attacks.

A06 Information Leakage and Improper EH

Applications can unintentionally leak information about theirconfiguration, internal workings, or violate privacy through avariety of application problems. Attackers use this weaknessto steal sensitive data, or conduct more serious attacks.


50/81

A07 Broken Authentication and SessionManagement

Account credentials and session tokens are often notproperly protected. Attackers compromise passwords,keys, or authentication tokens to assume other users'identities.

A08 Insecure Cryptographic Storage

Web applications rarely use cryptographic functions

properly to protect data and credentials. Attackers useweakly protected data to conduct identity theft andother crimes, such as credit card fraud.


51/81

A09 Insecure CommunicationApplications frequently fail to encrypt networktraffic when it is necessary to protect sensitivecommunications.

A10 Failure to Restrict URL Access

Frequently, an application only protects sensitivefunctionality by preventing the display of links or

URLs to unauthorized users. Attackers can use thisweakness to access and perform unauthorizedoperations by accessing those URLs directly.


52/81

LIVE DEMO

OWASP Top 10 Explained

Application VA

Web Application Pen-Test


53/81

Practical OWASP Top 10 Web Application Attacks

Application Vulnerability Assessment

Web Application Pen-Testing


54/81

The Security Development Lifecycle (SDL) is a securityassurance process that is focused on software development.

As a company-wide initiative and a mandatory policy since2004, the SDL has played a critical role in embedding security

and privacy in software and culture at many companies.

Combining a holistic and practical approach, the SDL aims toreduce the number and severity of vulnerabilities insoftware.

The SDL introduces security and privacy throughout allphases of the development process.


55/81

The four maturity levels of the SDL Optimization Model


56/81

SDL Optimization Model with capabilities and maturity levels


57/81

Simplified SDL Security Activities


58/81


59/81

PART II


60/81


61/81


62/81


63/81


64/81


65/81

Microsoft Case Study Microsoft Windows 2000

Microsoft SQL Server 2000

Microsoft SQL Server 2005

Microsoft Windows XP

Microsoft Windows Vista

Microsoft Exchange Server 2000


66/81


67/81


68/81


69/81


70/81


71/81

LIVE DEMO

Code Review


72/81

Using SDL Tools Threat Modeling

Code Review


73/81


74/81

References: http://channel9.msdn.com/wiki/securitywiki/applicati

onsecuritymethodology/

http://channel9.msdn.com/Wiki/SecurityWiki/WebApplicationSecurity/

http://msdn.microsoft.com/en-us/library/ms994921%28v=MSDN.10%29.aspx

http://channel9.msdn.com/Wiki/SecurityWiki/WebServicesSecurityChecklist/

http://channel9.msdn.com/Wiki/SecurityWiki/ArchAndDesignSecurityChecklist/
http://channel9.msdn.com/wiki/securitywiki/applicationsecuritymethodology/http://channel9.msdn.com/wiki/securitywiki/applicationsecuritymethodology/http://channel9.msdn.com/Wiki/SecurityWiki/WebApplicationSecurity/http://channel9.msdn.com/Wiki/SecurityWiki/WebApplicationSecurity/http://msdn.microsoft.com/en-us/library/ms994921(v=MSDN.10).aspxhttp://msdn.microsoft.com/en-us/library/ms994921(v=MSDN.10).aspxhttp://channel9.msdn.com/Wiki/SecurityWiki/WebServicesSecurityChecklist/http://channel9.msdn.com/Wiki/SecurityWiki/WebServicesSecurityChecklist/http://channel9.msdn.com/Wiki/SecurityWiki/ArchAndDesignSecurityChecklist/http://channel9.msdn.com/Wiki/SecurityWiki/ArchAndDesignSecurityChecklist/http://channel9.msdn.com/Wiki/SecurityWiki/ArchAndDesignSecurityChecklist/http://channel9.msdn.com/Wiki/SecurityWiki/ArchAndDesignSecurityChecklist/http://channel9.msdn.com/Wiki/SecurityWiki/WebServicesSecurityChecklist/http://channel9.msdn.com/Wiki/SecurityWiki/WebServicesSecurityChecklist/http://msdn.microsoft.com/en-us/library/ms994921(v=MSDN.10).aspxhttp://msdn.microsoft.com/en-us/library/ms994921(v=MSDN.10).aspxhttp://msdn.microsoft.com/en-us/library/ms994921(v=MSDN.10).aspxhttp://channel9.msdn.com/Wiki/SecurityWiki/WebApplicationSecurity/http://channel9.msdn.com/Wiki/SecurityWiki/WebApplicationSecurity/http://channel9.msdn.com/wiki/securitywiki/applicationsecuritymethodology/http://channel9.msdn.com/wiki/securitywiki/applicationsecuritymethodology/


75/81

FINAL LAB

Challenge Exercises


76/81

Input Validation Do validate input: length, range, format and type.

Do constrain, reject, sanitize input.

Dont trust input.

Authentication

Do use strong password policies.

Do encrypt communication channels to secure

authentication tokens. Do use HTTPs only with Forms cookies.

Dont store credentials.


77/81

Authorization Do use least privilege accounts.

Do consider granularity of access.

Do enforce separation of privileges.

Configuration Management Do use least privileged service accounts.

Do use strong authentication and authorization onadministrative interfaces.

Do avoid storing sensitive information in the web space. Dont store credentials in plaintext.

Dont use the LSA.


78/81

Sensitive Data Do enforce separation of privileges.

Do encrypt sensitive data over the wire.

Do secure the channel

Dont store secrets in software.

Session Management Do partition site by anonymous, identified and

authenticated.

Do reduce the timout. Do avoid storing sensitive data in Session.

Do secure the channel.


79/81

Parameter Manipulation Dont trust fields the client can manipulate (Query string,

Form fields, Cookie values, HTTP headers).

Exception Management Do use structured exception handling (try-catch).

Do only catch and wrap exceptions if the operation adds

value/information.

Don't reveal sensitive system or app info. Don't log private data (passwords ... etc.).


80/81

Cryptography Do use CryptoServiceProvider for random numbers.

Do avoid key management (use DPAPI).

Do Cycle your keys.

Dont roll your own (XOR is not encryption).

Auditing and Logging Do identify malign or malicious behavior.

Do know your baseline (what does good traffic look like).

Do instrument to expose behavior that can be watched (thebig mistake here is typically app instrumentation iscompletely missing).


81/81

Application Security and Secure Programming

Documents

Transcript of Application Security and Secure Programming