Fundamentals of Application Security

8/10/2019 Fundamentals of Application Security

1/57

Fundamentals of Application Security

Table of Contents:

Course Overview and Objectives

Introduction

IntroductionWhat is s ecurity?What is software security?Cost of Security Defects

Threat Terminology

Module Summary

Challenge Security Misconceptions

Challenge Security MisconceptionsThe Changing Attack ProfileFunctional Testing versus Security TestingSecurity BugsAll Software Has BugsPatches Do Not Guarantee SecurityInternal Threats

Module SummaryOWASP

OWASPIntroduction to OWASP

SQL Injection

Key Concepts of SQL InjectionPreventing SQL Injection

Cross-site Scripting (XSS)

Key Concepts of Cross-s ite scripting (XSS)Impact of XSSIdentifying XSS FlawsPreventing XSS Flaws

Broken Authentication and Session Management

Session Hijacking

Preventing Session HijackingExample of Session Fixation

Insecure Direct Object Reference

Key Concepts of Insecure Direct Object ReferenceDirectory TraversalsAddressing Directory Traversal Issues

Cross-Site Request Forgery (CSRF)

Key Concepts of Cross-Site Request Forgery (CSRF)Executing CSRF AttacksPreventing CSRF

Security Misconfiguration

Security MisconfigurationSecurity Misconfiguration: Dynamic Threat EnvironmentMitigating Security Misconfiguration: Repeatable Hardening

Insecure Cryptographic StoragePoorly Implemented Cryptography

Failure to Restrict URL Access

Insufficient Transport Layer Protection

Secure Sockets Layer and Transport Layer Security (SSL and TLS)Internet Protocol Security (IPSec)

Unvalidated Redirects and Forwards

Unvalidated Redirects and ForwardsMitigating Unvalidated Redirects and ForwardsTable Indirection Technique

Threats from earlier OWASP Top 10 List

Threats from earlier OWASP Top 10 ListMalware

Malicious File ExecutionInformation Leakage and Improper Error Handling

Information Leakage and Improper Error HandlingPreventing Information Leakage and Improper Error Handling

Module Summary

Security Principles

Fundamentals of Application Security 07/01/2015

https://sony.absorbtraining.com/courses/cl ients/317/Courses/Sony/fund_of_appli_security_for_sony_170513/CourseFiles/print.htm# 1 / 57


2/57

Security PrinciplesStructural SecurityPrinciple of Leas t PrivilegeTest EverythingModule Summary

Security Goals and Controls

Security Goals and Controls

Authentication

AuthenticationAuthentication ConsiderationsAuthorization

Authorization ConsiderationsAuthorization Considerations

Module Summary

Security in the SDLC

Security in the SDLCEstablishing Security RequirementsCategorizing ThreatsPrioritizing Threat MitigationDeveloping Secure CodeOverview of Security TestingTesting for Specific Types of VulnerabilitiesLeveraging Security Testing ToolsStop and Think!Module Summary

Locating Additional Res ources (1 of 3)Locating Additional Res ources (2 of 3)eknowledge Solutions


https://sony.absorbtraining.com/courses/cl ients/317/Courses/Sony/fund_of_appli_security_for_sony_170513/CourseFi les/print.htm# 2 / 57


3/57

Course Overview and Objectives

Just like functionality, performance, and reliability, se curity is another

crucial component of an applications quality. Recognizing the risk that

software vulnerabilities represent, understanding their root causes, and

addressing these issues early in the software development lifecycle are

essential for being able to help your organization build secure software.

Course Prerequisites

This course requires that you meet the following prerequisites:

Programming knowledge and experience.

Course Objectives

Upon completion of this course, you wil l be able to:

Understand the attacker mindset and what is at risk.Recognize the i mportance of managing software security risk and the

consequences of failing to do so.Challenge security misconceptions.Understand common security vulnerabilities and their mitigations.Understand security principle s.Understand key security goals and controls.Understand how security fits into the software development life cycle

(SDLC).

Narration:

Just like functionality, performance, or reliability, security is another crucial component of an

applications quality. But what does software security mean? And why should you care about it?

Recognizing the risk that software vulnerabilities represent and understanding their root causes isessential to enable you to help your organization build secure software. This course will teach you theactivities that an organization needs to undertake to ensure that the software it develops canwithstand malicious attacks.

This course assumes that you possess basic computer skills and a basic knowledge of the softwaredevelopment process.

By the end of this course, you will be familiar with the main characteristics of a secure softwaredevelopment lifecycle and the activities that your organization should perform to develop securesoftware. Furthermore, you will recognize the need to address software security in your everydaywork.

Introduction

Introduction

Module Overview

This module will help you understand the importance of designing

and maintaining software security throughout the software

development lifecycle. You will learn the fundamentals of secure

software design, how to align security decisions with corporate

policies and strategies, and how sof tware security failures can lead

to meaningful business risks.

Module Objectives

After completing this module you will be able to:

Understand the importance of software security.Understand the cost of security defects.Understand threat and risk management terminology.Distinguish between types of attackers and their motivations.

Narration:This module will help you understand the importance of designing and maintaining softwaresecurity throughout the software development lifecycle. You will learn the fundamentals ofsecure software design, how to align security decisions with corporate policies and strategies,and how software security failures can lead to meaningful business risks. The module definesthreat terminology and helps you understand how threats are evaluated using threat modelingtechniques. Also demonstrated are guidelines on identifying attacks and understanding theattackers motivations. Finally, the module explains why a consistent assessment methodologyis required to ensure secure software implementations.




4/57

What is security?

Narration:Information security seeks to protect the confidentiality, integrity, and availability of protectedinformation and systems. These three principles of information security are called the CIAtriad. Confidentiality means that private or proprietary information is protected fromunauthorized disclosure.

Integrity refers to the need to protect information from being modified or deleted byunauthorized users.

Maintaining availability of protected systems ensures that information and business functionswill be reliably accessible.

What is software security?

Software security is the design and implementation of application functionality intended to

ensure the confidentiali ty, integrity, and availability of protected information and systems.

Software security must align with:

ConfidentialityIntegrity

Software security is not the same as network security. Network security focuses on restricting

communication paths between systems. Software security focuses on the run-time logic within

applications and the processing of data passed inside of an allowed communication path.

Narration:Software security is the design and implementation of application functionality intended toensure the confidentiality, integrity, and availability of protected information and systems.

Software security is just one component of the larger effort of developing robust, reliable code.Insecure code is often also unstable, unreliable code, although this is not always true.

Many people confuse software security with network security. Network security primarilyfocuses on the protection of an organizations servers and computer infrastructure with thehelp of firewalls and intrusion-detection techniques. These mechanisms control the flow ofdata between networked systems.

On the other hand, software security focuses on protecting information and resources madeaccessible by applications and programs running on computer systems.

A good software security policy can trace its roots to larger corporate risk-managementpolicies. Software security is most effective when developed with the framework of an overallsecurity and risk-management strategy adopted by your organization.




5/57

Cost of Security Defects

The cost of removing a security vulnerability increases exponentiall y as one progresses along

the software development lifecycle. Industry studies have shown that the total cost of removing

a security vulnerability during testing is less than 2 percent of the cost of removing i t after

deployment. Removing a defect even earlie r, during design, is far cheaper than removing it

during testing.

Narration:The longer it takes to find a security bug, the more money is spent fixing it. Imagine that asecurity bug is found in a piece of popular desktop software; it would be expensive to fix. Thereis the immediate damage to the reputation of the software vendor and customers could incur

losses as a result of active exploitation. The vendor must make a patch, warn all theircustomers, and provide them with the patch. The patch must be tested and deployed. If youare interested in reducing your total cost of securing your application, make it a point todiscover security vulnerabilities as quickly as possible in your application. Do not wait until yourcustomer discovers a vulnerability, or falls victim to a security breach, before you fix it.

Threat Terminology




6/57

Module Summary

Understandtheimportanceof softwaresecurity

Understand the importance of software security

Security is defined as protecting information and systems from

unauthorized access, use, disclosure, disruption, modification, or

destruction. Confidentiality, integrity, and availability are the three main

components of information security and they form the CIA triad. Software

security means ensuring proper functioning of the software or an

application running on an organizations network even after an

unauthorized, malicious attack takes place.

It is critical for every organization to understand the risks a security failure

can cause and implement effective risk-management techniques in order

to reduce the likelihood of a costly incident.

You may click each objective above in order to learn more.

Click here to go over this section again.

Understandthe cost ofsecuritydefects

Understand the cost of security defects

Organizations need to assess the software they develop at various stages

of the software development life cycle. The cost of finding bugs in theinitial stage is much less compared to finding bugs at later stages.



Understandthreat andriskmanagementterminology

Understand threat and risk management terminology

To get a deeper insight of software security, you need to be wel l-versed

with various terms associated with threats and security. Threats can be

categorized based on the goals and purposes of the attacks. By analyzing

risks, you can determine the probability of the occurrence of a problem. It

also helps you to ide ntify the impact of a problem if it were to occur.



Distinguishbetweentypes ofattackersand theirmotivations

Distinguish between types of attackers and their motivations

In order to conduct proper threat modeling and design appropriate

defense s, it is important to understand the different types of attackers,

recognize their motives, and appreciate their skill sets. Not all sof tware

requires the same level of se curity, so accurate asset identifi cation and

threat modeling is essential to a wel l-designed risk management plan.






7/57



Module Overview

This module highlights common misconceptions around

application security. We will e xplain each of these

misconceptions, explaining the risks these misunderstandings can

pose as well as steps you can take to avoid these common pitfalls.

Module Objectives


Describe common security misconceptions.Explain how to avoid common security misconceptions.

Narration:This module highlights common misconceptions around application security. We will explaineach of these misconceptions, explaining the risks these misunderstandings can pose as well assteps you can take to avoid these common pitfalls.

The Changing Attack Profile

Most people tend to think of security as a network problem. Their answer is to protect the

boundary of a system using firewall s and antivirus software.

The truth is that security is a software problem and network insecurities usually result from

flaws in appli cations running on the system or poor configurations.

It is estimated that over 70 percent of attacks against a companys ne twork are at the

Application Layer, not at the system or network layer.

Narration:Most people tend to think of security as a network problem and the common answer tosecurity questions is to protect the boundary of a system with firewalls and Antivirus software.However, in reality, security is a software problem. Most insecurities, including networkinsecurities, result from flaws in applications running on the system or because of poorconfigurations.

According to Gartner, over 70 percent of attacks on a companys network are at theApplication Layer, not at the system or network layer.

Network security does little to protect sites from an application-layer attack. For example, aproperly constructed and encrypted SSL Web request bypasses the firewall and is completelyunseen by a Network Intrusion Detection System. With that said, if attackers gain accessthrough the application layer, they can bypass most of the intrusion detection, hide behind SSL,

and enter an application database directly. Therefore, the general hack method is that anattacker will attempt to penetrate the layer thats appropriate for the asset theyre trying tohack.




8/57

Functional Testing versus Security Testing

Functional Testing:

Functional testing verifies that the application does what it is supposed to do.It includes applying inputs to verify correct outputs.Functional testers ask "What is the sof tware supposed to do?"

Security Testing:

Security testing involves ve rifying that the application does not do what it is not supposed todo.

It includes applying inputs and verifying that no bad things occur.Security testers ask "What is the software not supposed to do?"

Narration:Development teams have been performing functional testing for decades and the process is

pretty well entrenched. Usually, we have a test plan that tells us what the application issupposed to do.

Say, for example, our test plan tells us to apply input A and that the application shouldgenerate output B. As a functional tester, thats what we doapply A, watch for B and whenwe see it, we mark the test case as passed. What we are doing here is verifying that theapplication did what it was supposed to do. But this is both too much and not enough forsecurity testing. Its too much because security testers dont bother with what the applicationis supposed to do. Its not enough because we should also be concerned with what theapplication is not supposed to do!

In other words, when we apply input A, we should not care about output B that is supposed tooccur. Instead, we should try to verify that a vulnerable output C does not occur. So unlike

functional testing, security testing anticipates and tests for insecure behaviors.

Security Bugs

Security bugs are much harder to spot than

functional bugsthey often have no vi sible ( to the

human eye) behavior.

To find security bugs:

Think about side effects and what sensitive datamight be exposed to.

Think backwardsthat is, instead of thinkingwhat shouldhappen, we nee d to think about whatshouldnthappen.

Narration:

When testing for security bugs, keep in mind that these types of bugs can be much harder to

spot than a functional bug. They are often the result of side effects or the interactions ofmultiple bugs that result in an exploitable outcome. Security testing requires you to think firstabout the possible threats to an application, the undesirable outcomes, and then progress

from the threat to the attacks that could realize that threat.




9/57

All Software Has Bugs

All software will have bugs, even the best developers make mistakes. Some of these bugs will

inevitably resul t in security vulnerabilities. Factor time into your projects to think specifically

about security. If you conduct assessments of security early, fi nd security bugs before its too

late, you may save a lot of time and money.

Narration:Even the best developers make mistakes. Practically speaking, all software has bugs, and someof those bugs, regardless of the security controls used, will result in a security vulnerability thatmay cause harm to your users or data. It is a common fallacy that security features will protectagainst all security problems. A security feature is typically designed to protect against onespecific attack such as encryption protecting against eavesdropping. Encryption cannot protectagainst SQL injection, buffer overflows, and other very common vulnerabilities.

Consider vulnerability assessments as a benefit to application development. U.S. $1 spent upfront on vulnerability assessment saves U.S. $10 during development and U.S. $100 afterrelease. Finding vulnerability in your design means that you have the opportunity to redesignmore securely. However, if you find vulnerabilities during the development phase, you need tospend time and money on changing the design, which will have a cascading impact on yourimplementation. If you find vulnerabilities during testing or after the software has beenreleased, you need to change the design and rewrite code to close the vulnerabilities.

Patches Do Not Guarantee Security

Releasing a patch may result in the resolution of a known security vulnerability but even patches

can have bugs. When deciding to patch, evaluate the risk of introducing new bugs and new

vulnerabilities against the damage caused by the vulnerabili ty you are patching.

When you do patch a vulnerability, take the time to understand the root cause. Otherwise, you

may patch a symptom and have to continue re-patching as attackers discover workarounds and

related vulnerabilities.

Narration: Whether you are modifying, fixing, or patching code, all maintenance tasks must be evaluatedfor risk so that maintaining your application does not introduce security flaws that were notthere prior to maintenance. Patches can fix security vulnerabilities and other bugs, and canimprove the usability or performance of your application. Though meant to fix problems,

poorly designed patches can sometimes introduce new problems.

When deploying a patch, bear in mind that patches only fix symptoms of known problems.Patches prevent an attacker from using a known attack vector. There may be other problemsin your software that you do not know about yet. In addition, patches do not always addressthe root cause of problems and may actually introduce new functional or security bugs.




10/57

Internal Threats

Insider attacks are a threat that needs to be considered when developing your application:

Attackers may already be inside the defended perimeter.29 percent of all distinguishable attacks are from inside rs.Internal attackers have far more access to data and systems than outsiders.The clueless and careless insi ders also may bring external threats inside.Need to consider internal threats in your solution design.Internal systems are not always safer from attack than external systems.

Narration:Internal sources of threats cannot be ignored because its estimated that 29 percent of allattacks are conducted by insiderseither intentionally or by executing viruses unintentionally.Often attackers bounce the attack off of an internal user through XSS or a Trojan horse

program so the risk is almost as high as the external threat.

Insiders have far more access to data and systems than an external attacker and as a resultthey can cause much more damage. They can directly steal data from the data store andtransport that data out of the organization. Common methods for transporting data are smallUSB flash memory devices or sending the outbound data encrypted as an SSL transaction usingthe fast network bandwidth. The data can even be chunked into small files to not set off thesuspicious of data leakage products on a network.

Clueless insiders can also bring external threats inside by using an infected laptop, clicking an e-mail with a virus, and by browsing malicious sites that can attack your systems.

Consider internal threats in your solution design, treat all users as potentially hostile, and treatinternal data feeds to an application as not trusted. Remember that even the most trusteduser can be a hacker!




11/57

Module Summary

Describecommonsecuritymisconceptions

Describe common security misconceptions

Developers may have the misconception that security is important at

the network and operating system levels and that its not important at

the application level , however, networks and operating systems can do

very little to prevent attacks.

Similarly, developers also tend to believe that patches, functional tests,

Java and .NET, cryptography, client-side security checks, and firewall s

are good enough to protect applications. However, these too have their

shortcomings and cannot prevent application-level attacks.



Explain how toavoid commonsecuritymisconceptions

Explain how to avoid common security misconceptions

Its very important for you to implement robust security in your

application code and conduct regular security tests. When conducting

security tests, you should l ook out for behaviors that should not

happen. Additionally, you should be wary of internal attacks and designyour system with the insider threat in mind. If you choose to use tools

such as Static Analysis Tools, Dynamic Analysis Tools, and Application

Vulnerability Scanners, be aware of their strengths and weaknesses so

they can be used most effectively.

Implementing security in application early helps prevent loss of money.

If you spend U.S. $1 on implementing application security during the

design phase, you may save U.S. $10 if the same problem was

discovered during the development phase and U.S. $100 after the

applications release.






12/57

OWASP

OWASP

Module Overview

Open Web Appli cation Security Project (OWASP) is an open-source

application security project. This module will help you understand

what OWASP is all about.

Module Objectives


Understand OWASP and its importance.Name each of the OWASP top 10 vulnerabilities.Understand the basics of the vulnerabilitie s and their impact.

Narration:This module will help you understand what Open Web Application Security Project (OWASP) is.First, you will be introduced to what OWASP stands for and why it is important in the softwaredevelopment lifecycle. Then, this module will provide details about the top 10 vulnerabilitieslisted under OWASP and describe how these vulnerabilities can evolve over time as newattacks are discovered. By the end of this module, you will know about the basics ofvulnerabilities and their impact on application software.

Introduction to OWASP

Open Web Application Security Project (OWASP)

OWASP was founded in 2003 and focuses on improving the security of Web application software.

OWASP is an open-source Web application security project. Members of this project include a

variety of security experts from around the world who have shared their expertise to produce a

list of the most critical Web application security flaws.

OWASP Top 10 is a document created for Web application security, which highlights the 10 most

important Web application vulnerabilities.

Note:The official OWASP Web site is www.owasp.org.

Narration:A popular trend, which started originally with the SANS Institute, is for organizations to publishannual Top 10 lists of each years most common security vulnerabilities. Since 2003, the OpenWeb Application Security Project (OWASP.org) has published such a list for Web applicationsecurity. The Open Web Application Security Project (OWASP) is a worldwide free and opencommunity focused on improving the security of Web applications.

Security experts from around the world gather to share their expert ise with each other andcome up with the top 10 security vulnerabilities of the year. These vulnerabilities, collated asthe OWASP Top Ten, provide a powerful awareness document for Web application security andrepresent a broad consensus about the most critical Web application security flaws. Therefore,adopting the OWASP Top Ten is an effective first step towards changing the softwaredevelopment culture within your organization into one that produces more secure code.

SQL Injection

Key Concepts of SQL Injection

SQL injection is a software vulnerability that occurs when data entered by users is sent to

the SQL interpreter as a part of an SQL query.

SQL injection exploits security vulnerabilities at the database layer. By exploi ting the SQL

injection flaw, attackers can create, read, modify, or delete sensitive data.

Attackers provide specially crafted input data to the SQL interpreter and trick the

interpreter to execute unintended commands.

Narration:SQL injection is a software vulnerability that occurs when data entered by users is sentto the SQL interpreter as a part of an SQL query. SQL injection exploits securityvulnerabilities at the database layer. By exploiting the SQL injection flaw, attackers cancreate, read, modify, or delete sensitive data.

Attackers utilize this vulnerability by providing specially crafted input data to the SQLinterpreter in such a manner that the interpreter is not able to distinguish between theintended commands and the attackers specially crafted data. The interpreter is trickedinto executing unintended commands.


http://www.owasp.org/


13/57

Preventing SQL Injection

In order to prevent or mitigate SQL injection vulnerabilities:

Use input validation for length, type, syntax, and business rules.Grant least privile ges to those with database permissions.Use strongly typed parameterized queries.Show care when using stored procedures.

Narration:SQL injection can be prevented if you adopt an input validation technique in which userinput is authenticated against a set of defined rules for length, type, and syntax andalso against business rules.

You should ensure that users with the permission to access the database have the leastprivileges. Additionally, do not use system administrator accounts like sa for Webapplications. Also, you should always make sure that a database user is created only fora specific application and this user is not able to access other applications. Another

preventive measure is to remove all stored procedures that are not in use.

Use strongly typed parameterized query APIs with placeholder substitution markers,even when calling stored procedures

Show care when using stored procedures since they are generally safe from SQLinjection. However, be careful as they can be injectable (such as via the use of exec() orconcatenating arguments within the stored procedure).




14/57

Cross-site Scripting (XSS)

Key Concepts of Cross-site scripting (XSS)

Key Concepts of Cross-site scripting (XSS)

XSS is a Web-based attack performed on vulnerable Web appli cations.In XSS attacks, the victim is the user and not the appli cation.In XSS attacks, malicious content is de livered to users using JavaScript.

The 3 type of XSS vulnerabilities are:

PersistentReflective (non-persistent)DOM-based

Narration:As the name suggests, Cross-site scripting (XSS) is a Web-based security vulnerability inwhich a user instead of a Web application is attacked. During such an attack, avulnerable Web application is exploited to deliver malicious content to users via script.This content can include HTML or JavaScript code and appear as a persistent, areflective or non-persistent, or a DOM-based attack.

Impact of XSS

By exploiting XSS vulnerabilities, an attacker can perform malicious actions, such as:

Hijack an accountSpread Web wormsAccess browser history and clipboard contentsControl the browser remotelyScan and exploit intranet appliances and applications

Note:In an attack exploiting XSS vulnerabilities, anything that can be scripted, can be used

to attack a user.

Narration:When attackers succeed in exploiting XSS vulnerabilities, they can gain access toaccount credentials. They can also spread Web worms or access the users computerand view the users browser history or control the browser remotely. After gainingcontrol to the victims system, attackers can also analyze and use other intranetapplications.

Identifying XSS Flaws

XSS vulnerabilities may occur if:

Input coming into Web applications is not validated.Output to the browser is not HTML encoded.

XSS allows an attacker to embed malicious script to be run by an unsuspecting browser,

using:

JavaScriptVB ScriptActiveXHTMLFlash

Be suspicious any time user-provided input is echoed to the page, such as from:

Form inputReverse DNS lookupHidden tags

Narration:An XSS flaw is likely to occur if the input data coming into Web servers is not validatedat the source or if data output to the user is not HTML encoded.

When incoming data isnt validated, XSS flaw allows attackers to embed malicious scriptthat can be executed on an unsuspicious Web browser using JavaScript, VB Script,

ActiveX, HTML, or Flash.

HTML encoding the output to the user will make sure any script is rendered as text andnot executed by the browser.

Additionally, you should be suspicious any time user-provided input is echoed on the

page. This applies to input such as form input, reverse DNS lookup, and hidden tags.




15/57

Preventing XSS Flaws

In order to avoid the XSS vulnerabilities, you can perform the following actions:

URLEncode all user input returned as part of URLs (convert ?, &, /, , and spaces to theirrespective URL encoded equals).

HTMLEncode all user input returned as part of HTML.Convert all user input to a single character encoding before parsing.

Narration:To prevent XSS vulnerabilities, you should URLEncode all user input that is returned as

part of URLs. This will convert ?, &, /, , and spaces to their respective URL encodedequals. Additionally, you should HTMLEncode all user input returned as part of HTML.This will also convert special characters into their respective HTML encoded equals.

Last but not the least, you should convert all user input to a single character encodingbefore parsing. This applies to Single/Double Hex Encoding, Unicode Encoding, and UTF-8 Parsing.




16/57

Broken Authentication and Session Management

Session Hijacking

Session hijacking is the alteration of session data to impersonate the session data of

another user, taking over the users session. Session hijacking can be done in several

ways:

Attacker intercepts the communication between the client and server and steals a vali dsession ID.

Attacker tries to steal se ssion information from the cookies stored in the userscomputer.

Guess a predictable session ID.

Narration:The Web is inherently connectionless and stateless and developers rely on data sent tothe client and returned with each new request to track the users session. Improperhandling of such information can lead to an attack where an attacker alters sessiondata and impersonates the session data of another user, hijacking the users session.

After attackers know where this information is stored, they simply alter the informationin such a way that the server will view it as the valid session of another user whosesession is hijacked.

Session hijacking can be done in several ways. For example, an attacker can interceptthe communication between a client and a server and steals a valid session ID.

Alternatively, an attacker can try to steal session information from the cookies storedon the users computer. Finally, if session IDs are predictable an attacker could guess avalid one.

Preventing Session Hijacking

In order to prevent or mitigate Session hijacking:

Use secure random session IDs such as JSESSIONID.Bind the session ID to another piece of identifying information, e.g. users IP address.Expire sessions on logout and after a set period of inactivity.

Narration:To develop a secure application, you should restrict the instances of session hijacking by

following some simple guidelines.

Most Web frameworks provide us with secure random session IDs such as JSESSION ID.You need to ensure that all other session data should be stored on the server side andreferenced with this JSESSION ID. Using a secure random ID will make guessing difficult

for an attacker and will not be able to guess another valid session ID.

An application developer should also bind the session ID to some other piece ofidentifying information, such as the IP address of the user. This will make it moredifficult for an attacker to use a stolen, valid session ID.

As soon as a user logs out of a session, the session should expire. The session should alsoexpire after a set period of inactivity. This ensures that an attacker will not be able toreplay a valid session at a later stage.




17/57

Example of Session Fixation

Narration:Lets observe an example where an attacker induces a client to establish a session withthe target software using a session identifier provided by the attacker.

Analysis indicates that the attacker either has used a malicious link or has leveraged onan earlier attack, such as XSS.

As soon as user requests for a specified application with a valid session ID, theapplication authenticates the user. However, the attacker already knows the samesession ID. Therefore, the attacker will now be able to use the session identifier for

their own transactions.

So what does this imply? The attack leverages the fact that the target software eitherrelies on client-generated session identifiers or maintains the same session identifiersafter privilege elevation.

How to prevent such instances? To prevent session hijacking it is important to invalidatethe unprivileged session ID and provide a new session ID after authentication. It is alsoimportant to ensure correct logout, password management, and timeout functions tohelp mitigate various instances of session fixation and hijacking.




18/57

Insecure Direct Object Reference

Key Concepts of Insecure Direct Object Reference

Insecure Direct Object Reference occurs when a developer exposes a reference to an

internal implementation object.

Attackers can easily manipulate an Insecure Direct Object Reference to gain unauthorized

access to confidential obje cts and exploit them.

Avoid exposing direct references. If they must be used, perform an authorization check.

Narration:Insecure Direct Object Reference is a security vulnerability that occurs when adeveloper accidentally or due to negligence happens to create a URL or form

parameter exposed to the user with a reference to an object, such as a file, directory,database record, or a key, which is confidential to the organization.

Due to such an exposure, attackers can easily manipulate the reference and gain accessto other confidential objects and view or modify them.

The best protection is to avoid exposing direct object references to users by using anindex, indirect reference map, or another indirect method that is easy to validate. If adirect object reference must be used, ensure that the user is authorized before using it.

Directory Traversals

Challenge:Request a filename from user

Problem:User may input correct filename

OR

May attempt to e scape Application Directory by:

using / or \ to access root directoryusing .. to access parent directorymanipulating symbolic links (i.e . shortcuts)

Narration:Directory traversals can happen when a Web application accepts a filename from theuser but doesnt validate that the filename does not allow the user to access

unintended locations in the file system.




19/57

Addressing Directory Traversal Issues

In order to prevent or mitigate directory traversal:

Examine code against a user-specified fi leAlways use Expli cit pathsDefine application-specific MYAPP_PATHUse regular expressions to opt in known good paths

For example:

^[cd]:(?:\\\w+)+\\\w{1,32}\.(txt|jpg|gif)

Narration:To avoid directory traversal, you should examine application code against a user-specified file. You should avoid relative or default paths. In addition, you should neveruse the environment variable path for locating files because they can be changed andcannot be relied upon. Therefore, you should always define explicit, application-specific

paths, such as MYAPP_PATH.

To do this, you can use a regular expression that will allow you to use the files presenton paths already known, verified, and secured by you. Note the sample expressiondisplayed on the screen. In this expression, the displayed path is alphanumeric, whichallows the application to accept txt, jpg, or gif files from the C or the D drive of theserver hosting the application.




20/57

Cross-Site Request Forgery (CSRF)

Key Concepts of Cross-Site Request Forgery (CSRF)

CSRF is a malicious attack where the attacker exploits the users Web browser to execute

undesired actions on behalf of the user. These actions include:

Transferring fundsChanging passwordsPurchasing items using online shopping

Narration:Cross-Site Request Forgery (CSRF) is a malicious attack that tricks the users Webbrowser to perform undesired actions so that they appear as if an authorized user is

performing those actions.

For example, if an attacker is able to modify the content viewed by a users browser,perhaps with a hostile Web site, when the user is checking an online bank account, theattacker can change the users transaction password to control the users actions andtransfer funds to the attackers account.

Executing CSRF Attacks

CSRF attackers use the functionalities of the v ictims browser against them.

When a user accesses a Web site and logs on to his account, the users credentials are

stored within the Web sites cookie.

The Web browser automatically associates the cookie with the actions the user performs

on the Web site.

Since the user was authenticated by the Web site, i f an attacker exploits the CSRF

vulnerability at this stage, the Web application is not able to distinguish betwee n a valid

action performed by the user or a malicious action initiated by an attacker.

Narration:To exploit CSRF vulnerability, the attacker uses the functionality of the victims Webbrowser. When the victim is accessing a Web site using his login ID and password, thevictims credentials are automatically saved to the Web sites cookie. The Web browser

will always associate the user with this cookie whenever the user performs any actionon this Web site.

Since the user was authenticated by the Web site, if an attacker exploits the CSRFvulnerability at this stage, the Web application is not able to distinguish between a validaction performed by the user or a malicious action initiated by an attacker.




21/57

Preventing CSRF

The most common defense is to append challenge tokens to each request. These

challenge tokens must be associated with the users sessi on.

Advantages of using challenge tokens are:

Attackers will not be able to provide a valid token of thei r own to utilize within theattack.

Developers can ensure that the request is valid and not coming from a source otherthan the user.

Narration:The most common method to prevent CSRF attacks is to append challenge tokens toeach request and associate them with the users session. By including a challenge tokenwith each request, the developer can ensure that the request is valid and not coming

from another source other than the user.




22/57



After you deploy your Web application online,it undoubtedly will encounter a number ofattacks. To prevent these attacks from beingsuccessful, you need to follow soundoperational practices related to se curity.

Inadequate operational practices can lead to

security compromises using ex ploits of securityfeatures or of known vulnerabilities. Improperpermissions may allow malicious users toperform actions they shouldnt.

Misconfiguration Types

Missing patches:Patches, hotfixes, servicepacks, and updates contain the latest securityfixes and need to be applied when they areavailable.

Misconfigured or disabled security features:If a security feature is disabled or notconfigured, it cannot provide protection.

Default accounts:Default accounts mayallow a malicious user to automatically loginwith the credentials published in productdocumentation.

Unnecessary/unused services or features:These represent an increased risk for securityproblems. Bugs exist even in the best-writtencode, By disabling or removing unused andunnecessary services, code, and libraries, youlimit the amount of code that needs to bemaintained and patched. When in doubt, turnfeatures off, and turn them back on only if youneed them. Of course, verify all changes andremovals before putting them in production.

Administrative back doors:Administrativeback doors are known as front doors in thehacking community. Its absolutely critical tosecure these administrative endpoints givenwhat they are: the keys to the kingdom. Do notrely on a malicious user overlooking thefunctionality; it can always be discovered.Security through obscurity is no security at all.

Parts of the Stack Vulnerable toMisconfiguration

OSEnvironment/PlatformWeb or Application ServerDatabase ServerApplication(s)Components and LibrariesServices

Narration: After you deploy your Web application online, it undoubtedly will encounter a numberof attacks. To prevent these attacks from being successful, you need to follow soundoperational practices related to security.

Inadequate operational practices can lead to security compromises using exploits ofsecurity features or of known vulnerabilities. Improper permissions may allow malicioususers to perform actions they shouldnt.

A few misconfiguration types, such as missing patches, misconfigured or disabledsecurity features, default accounts, unnecessary or unused services or features, andadministrative backdoors, can render a Web application vulnerable to attacks.

These security misconfigurations can happen in any part of your system.




23/57

Security Misconfiguration: Dynamic Threat Environment

The online world is a dynamic envi ronment wherethreats develop and manifest every single day. Tomitigate and maintain a secure environment, youneed a process that can quickly adapt to thesethreats. A repeatable process is required toconstantly reevaluate the environment andaddress new or growing threats, and shouldinclude the following:

Updating the environment:This includeschanges like adding or removing network

segments, and changing configuration.New products:New products or functionalitymay be needed to deal with a threat that did notexist when the application was released.

Service packs and patches:Use a regular processto apply the latest service packs, patches, hotfixes,and updates to all of your software, from top tobottom.

In addition, your development, test, and stagingenvironments should precisely match theproduction envi ronment. If your environmentsdont match, you might discover on release daythat your application doesnt work as expected.

For example, a Nasdaq breach in February of 2011,after investigation by FBI and the se cret service,was narrowed down to unpatched Windowssystems and poor firewall configurations. Whilethe core trading systems most likely remainedintact, it could not be determined how muchproprietary and client information was stolen.Unpatched systems could have been prevented byNasdaq avoiding downtime as a result ofinvestigations, loss of revenue and loss ofcustomer trust. Especially in this tough competitivemarket, there is no reason to be faced with thesame issues as Nasdaq.

GlobalSign, a leading digital certificate provider,was also breached late in 2011 as a result of anunpatched piece of open source software.Although fortunately the companies rootcertificate that is used to sign other digitalcertificates was not compromised, GlobalSign hadto halt certificate issuance for 9 days, faceadditional audits and most importantly lost i tspublic trust due to the breach.

GlobalSign states that the particular open sourcecode was not on the li st of software to be updated.It is important to keep an accurate inventory of allsystems and software they run. You cannot protectwhat you dont know you have.

Narration: Threats change constantly, and without processes that can adapt as quickly as thethreats, you cannot maintain a secure environment. A repeatable process is required toconstantly reevaluate the environment and address new or growing threats.

The process should include updating the environment with changes like adding orremoving network segments and changing configuration.

You may need to deploy new products or functionality to deal with a threat that did notexist when the application was released. In addition, you should have a regular processto apply the latest service packs, patches, hotfixes, and updates to all of your software,

from top to bottom.

In addition, your development, test, and staging environments should precisely matchthe production environment.

For example, a Nasdaq breach in February of 2011, after investigation by FBI and thesecret service, was narrowed down to unpatched Windows systems and poor firewallconfigurations. While the core trading systems most likely remained intact, it could notbe determined how much proprietary and client information was stolen. Unpatchedsystems could have been prevented by Nasdaq avoiding downtime as a result ofinvestigations, loss of revenue and loss of customer trust. Especially in this toughcompetitive market, there is no reason to be faced with the same issues as Nasdaq.

GlobalSign, a leading digital certificate provider, was also breached late in 2011 as aresult of an unpatched piece of open source software. Although fortunately thecompanies root certificate that is used to sign other digital certificates was notcompromised, GlobalSign had to halt certificate issuance for 9 days, face additionalaudits and most importantly lost its public trust due to the breach.

GlobalSign states that the particular open source code was not on the list of software to

be updated. It is important to keep an accurate inventory of all systems and softwarethey run. You cannot protect what you dont know you have.




24/57

Mitigating Security Misconfiguration: Repeatable Hardening

A well-defined process provides your first line ofprotection against a dynamic threat environment. Aregular, repeatable hardening process is required tomake sure your environment is protected against thelatest threats.

Keep the fol lowing in mind as you create andimplement your process:

Research all stack components for potentialvulnerabilities

Vendor/proj ect sites

http://www.symantec.com/security_response/SymantecSecurity Response Summarizes the current state ofactivethreats and vulnerabilities in popular software

http://nvd.nist.gov/National Vulnerability Databaseis acomprehensive list of vulnerabilities

Security sites

http://www.securityfocus.com/Site with securitynews andvulnerabilities. They also host the popular BugTraqmailing

list

http://www.us-cert.govUS Government Site focusedonimproving the nations cyber-security i nfrastructure

http://www.securitywizardry.com/radar.htmA nicegraphicalsummary screen of the current state of cyber-threatactivity

Security mail ing lists/aliases

BugTraq While it can be a chatty list, it providesinsite onhot of the press discovered vulnerabilities.CISSPForum

For Security professionals discusses current issueseffecting the state of cyber Security

Search for any additional information

Review all settings and configurations

Pay close attention to security fe atures

Look for standard recommendations for secureconfigurations ofyour platforms and applications from their vendors,standardsorganizations, and security organizations

Review all enabled features

Disable any unnecessary features

Repeat the process:

At regular intervals; monthly, bimonthly

Every time a deployment or configuration changes

Narration: A well-defined process provides your first line of protection against a dynamic threatenvironment. A regular, repeatable hardening process is required to make sure yourenvironment is protected against the latest threats.

Research each component of your application stack, and subscribe to security andpatch bulletin mailing lists and news groups where updates are announced. Use theinformation discovered in your research to apply updates or configure your system tomitigate new, unpatched vulnerabilities.

Next, you should review and document all settings and configurations, paying closeattention to security features. Make sure you document any changes.

Finally, repeat the process at regular intervals, and every time a deployment orconfiguration changes.

Remember to frequently review all enabled features, even though you did this whenyou deployed the product. Installers often turn on features you dont need, and service

packs and even administrators may enable feature youre not aware of.


http://www.securitywizardry.com/radar.htmhttp://www.us-cert.gov/http://www.securityfocus.com/http://nvd.nist.gov/http://www.symantec.com/security_response/


25/57


26/57

Poorly Implemented Cryptography




27/57

Failure to Restrict URL Access




28/57

Insufficient Transport Layer Protection

Secure Sockets Layer and Transport Layer Security (SSL and TLS)

SSL and TLS are commonly used to secure the channel between a browser and a Web

server.

It is application independent.It allows protocols like HTTP, FTP, and Telnet to be layered transparently on top of it.SSL supports a variety of cryptographic algorithms.

Narration:SSL/TLS is commonly used to secure the channel between a browser and a Web server.It is application independent and allows protocols like HTTP, FTP, and Telnet to belayered transparently on top of it.

SSL supports a variety of cryptographic algorithms. For example, during the"handshaking" process, it uses the RSA public-key cryptosystem, and after the keys areexchanged, it uses a number of ciphers including RC2, RC4, IDEA, DES, and triple-DES.

Internet Protocol Security (IPSec)

IPSec provides a transport level secure communication solution that can be used to secure

the data sent between two computers.

It is mostly used in Virtual Private Networks (VPNs).

It ensures confidentiali ty and authentication of all network traffic at the IP level.

Other features of IPSec are as follows:

It can provide some security services in the background with no impact on user or thedeveloper.

It does not provide user-level authentication.It uses the philosophy that only the OS configuration nee ds to change and not

individual applications.

Narration:IPSec, which is mostly used in Virtual Private Networks (VPNs), provides a transportlevel secure communication solution that can be used to secure the data sent betweentwo computers. It ensures confidentiality and authentication of all network traffic atthe IP level.

Another benefit of IPSec is that it can provide some security services in the backgroundwith no impact on user or the developer. Also, it does not provide user-level

authentication and uses the philosophy that only the OS configuration needs to changeand not the individual applications.




29/57



Unvalidated forwardscan allow a malicioususer to spoof your site.The malicious userprovides the victim withwhat looks like a link toyour site but actually

redirects the victim to amalicious location.Many authenticationsystems use redirectionto return a requester toan authorized URL afterlogin, so the user maynot notice that the siteis i ncorrect.

To protect anapplication againstunvalidated redirectsand forwards, you nee dto validate the input aswell as the referrerheader, which can becontrolled ormanipulated by amalicious user.

Results

Unvalidated redirectsand forwards can resultin the followingconsequences:

Complete spoof ofyour site. A phishingattack could redirect theclient to a maliciousWeb site. A malicioususer can also useredirects in combinationwith a CSRF attack. Forexample, if thevulnerable action checksthe referrer to validate

that it comes from yourvulnerable site, theunvalidated forwardmakes the mitigationinsufficient.

Bypassedauthorization checks. Inmost common Webplatforms, an API callexists that directlytransfers a client toanother location,bypassing authorizationchecks. If such an API isused to implement anunvalidated redi rector,a malicious user simplyneeds to use theredirect as the entrypoint to all other

resources on the site.

Narration: A URL that redirects you from its location to another is called a redirect or a forward.Authentication systems often use redirects to transparently inject authentication intoan unauthenticated request for a protected resource. Redirects are also used to recordan action. For example, links to a third-party site for advertisements often use aredirect to record that a client clicked an advertisement.

If a URL uses a parameter to indicate the redirect destination for the client, and theinput is not validated, the site is subject to unvalidated redirects and forwards. Like allevil input threats, the key to protecting an application against unvalidated redirectsand forwards is to validate the malicious input. You must also validate the referrerheader.

Unvalidated redirects and forwards can result in a complete spoof of your site. Aphishing attack could provide a valid link to your Web site in an e-mail message. But thelink actually redirects the client to a malicious Web site. A malicious user can also useredirects in combination with a CSRF attack. For example, if the vulnerable actionchecks the referrer to validate that it comes from your vulnerable site, the unvalidated

forward makes the mitigation insufficient.

Malicious users may also be able to bypass authorization checks. In most common Webplatforms, an API call exists that directly transfers a client to another location,bypassing authorization checks. If such an API is used to implement an unvalidatedredirector, a malicious user simply needs to use the redirect as the entry point to allother resources on the site.




30/57

Mitigating Unvalidated Redirects and Forwards

To mitigate unvalidated redirects and forwards, usethe following guidelines:

Never use internal transfer without authorizing theuser for the target URL.In general, it is far easier to usea redirect method, which will issue a 302 response tothe client and ask the client to make another requestfor the target URL. At that point, it will be like any

other request for the target.Wherever possible, restrict the usage of yourforward functionality to some set of authorized users,instead of all unauthorized users.

Use weblogs to identify potential code. Look forHTTP status codes in the 300 series: 301, 302, 303, and307.

Where possible, do not use redirect, or redirect tostatic locations.

When redirecting to a parameter, validate theparameter to make sure that it is an expected redirect.Use table indirection where possible to turn a dynamicset of potential choices into a table of valid keys. Atthe very least, allow only relative redirects.

Narration: To help protect against unvalidated redirects, never use internal transfer methodswithout first authorizing the client to the target URL. In general, it is far easier to use aredirect method, which will issue a 302 response to the client and ask the client tomake another request for the target URL. At that point, it will be like any other request

for the target.

Wherever possible, restrict the usage of your forward functionality to some set ofauthorized users, instead of all unauthorized users. Sometimes the hardest part ofmitigating unvalidated redirects and forwards is finding them. Scanning the Web logscan be very helpful to finding this code. Look for HTTP status codes in the 300 series:301, 302, 303, and 307.

Avoid redirects altogether, or redirect to a static location or a static set of locationswherever possible. When redirecting to a parameter, validate the parameter to makesure that it is an expected redirect.

Use table indirection to turn a dynamic set of potential choices into a table of valid keys.Limit your forward to pass control of another page in your own Web site.




31/57

Table Indirection Technique

If you have a potential set of valid locations that theclient is allowe d to redirect to, consider using tableindirection. Maintain a table of allowed URIs, and thenallow the client to specify the keys into the table onlyand not the actual URI itself.

When the key is returned, look up the URI in the tableand then redirect to that location.

In the following URL, the color blue indicates userinput, and the color grey is the unencoded value of the

redirect parameter.

/Login.aspx?redirect=%2fAccount%3Fid%3d1234(/Account?id=1234)

becomes

/Login.aspx?redirectKey=13m1=1234

Even if your system requires additional data to be sentto the location, the table indirection can still besuccessful. Simply take the additional parameter andcombine it with the URI value from the table. Be carefulof any type of injection attack here; even though youare restricting the malicious user, you still ne ed tovalidate the data in param1.

Narration: You can use the table indirection technique to mitigate unvalidated redirects andforwards. If you have a set of valid locations that the client is allowed to redirect to,consider using table indirection. Keep a table of the allowed URIs, and then allow theclient to specify the keys into the table only and not the actual URI itself. When the keyis returned, look up the URI in the table and then redirect to that location.

In the example on the screen, a redirection scheme for logging that takes a relativepath directly becomes a system that uses a redirect key instead. The key value willeither exist in the table or it wont, and a malicious user has little control over theredirect destination.




32/57



This concludes the current OWASP Top 10 list, which was released in 2010. The previous listreleased in 2007 included two additional threats that were replaced by securitymisconfiguration and unvalidated redirects and forwards. These threats, while no longerincluded in the current top 10 list, are still i mportant. They are:

Malicious File ExecutionInformation Leakage and Improper Error Handling

Narration: This concludes the current OWASP Top 10 list, which was released in 2010. The previouslist released in 2007 included two additional threats that were replaced by securitymisconfiguration and unvalidated redirects and forwards. These threats, while nolonger included in the current top 10 list, are still important. They are malicious fileexecution and information leakage and improper error handling.

We will look at these threats in detail in the next section.

Malware

Malware can be spread as file uploads or file attachments.

Malware is a malicious program that shouldnt be executing on a system.

A Worm is a self-propagating program.A Virus requires user action such as copying files to propagate.A Trojan Horse purports to be a benign or helpful program but harbors malicious

behavior.A Time Bomb may perform a malicious action after a predetermined date or time i s

reached

Narration:Malware is one of the most common malicious attacks that can be used for breachingapplication security. Attackers having access to upload or attach arbitrary files canspread malware from their computers to trusted systems. Then, remote or local usersof the application may inadvertently execute these files. There are three major types ofmalwares Worm, Virus, and Trojan Horse.

A Worm is a self-propagating program that takes advantage of either a vulnerability inan operating system or a common software to breach a system and start executingmalicious codes in the system. The Worm doesnt stop here, it then searches for othersystems with some vulnerability and repeats the process to spread itself. Worms canspread quickly and pose a major risk to a vulnerable network.

A Virus attaches them to an executable file infecting the file. When the infected file ismoved to another system and executed, other files on that system become infectedwith the virus. A virus uses system resources and other programs to reproduce itself.

A Trojan Horse is named after the famous Trojan Horse in Greek mythology. A TrojanHorse purports to be a beneficial program. However, it harbors malicious functionalitysuch as a keystroke logger for capturing passwords or remote access that will allow anattacker to attack and control a system. Users are tricked into installing the malware,which is often disguised as a browser toolbar, a media player, a video codec, or anelectronic greeting card.




33/57

Malicious File Execution

When user input is used to open fi les or execute commands, there is an opportunity for

malicious code execution.

Guidelines for Preventing Malicious Code Execution

Never expose file identifiers to user input.Never use unf iltered user input to craft a filename or an OS exec input.Dont allow user input to create server-side script or include fi les.

Narration: Malicious code execution can be prevented by following some guidelines. You shouldnever expose file identifiers to a user such that they become part of user input and canbe easily modified by them. Exposing file identifiers can also cause information leakageby allowing the user select the filename opened by the application. Moreover, if theapplication executes commands or scripts contained in the file, this can lead to themore serious malicious code execution.

Suppose user input is part of an OS shell or an exec command. Then the user can specifycommands to execute. Therefore, you should always filter user input going intosystem(), StartProcess(), java.lang.Runtime.exec(), System.Diagnostics.Process.Start()or similar APIs.

Another malicious code execution is an include file injection. An include file injectionoccurs when the user is able to specify a filename as input that gets included into arunning script under PHP. Script injection occurs when the user is able to specify inputthat is interpreted by the server-side scripting engine in PHP or ASP.




34/57

Information Leakage and Improper Error Handling

Information Leakage and Improper Error Handling

Information Leakage

Disclosing information in error messages is often

done because it helps normal users to fix errors

and help developers fix various problems.

Examples of error messages that are likely to

disclose i nformation are ODBC error messages,

authentication error messages, and others.

Improper Error Handling

Improper error handling can provide information

that can be used for attacking a system. For

example, error messages such as:

Running V4.1 with X module, can provideApplication/platform identification information.

Error encountered at line 123 in fi lethis_is_a_weak_app.asp can provide applicationimplementation details.

Invalid password supplied for user id xxxxx.

can disclose accurate user ids.

Narration:Disclosing information in error messages is often done because it helps normal users to

fix errors and help developers fix various problems. Examples of error messages that arelikely to disclose information are ODBC error messages, authentication error messages,and others.

Applications should handle error messages with a lot of restrictions. Improper errorhandling can provide information that can be used for attacking a system. For example,error messages should avoid application/platform identification information,implementation details, and information related to data quality.

Preventing Information Leakage and Improper Error Handling

Determine in advance:

What is reasonable and can be disclosed.What is not to be disclosed.

Think from an attackers perspective.

Use a standard error response for all sensitive data

errors. Such as An error has occurred while

accessing the database.

Narration:To prevent information leakage, one must segregate information based on some pre-defined criteria. You should determine in advance about which information is safe fordisclosure and which information needs protection.

The best way to determine the level of information confidentiality is by thinking from anattackers perspective and determining what the attacker can do with the information.

Even while developing error-handling messages for an application you should use astandard error response for all sensitive data errors. Just mention the macro problem,such as An error has occurred accessing the database.




35/57

Module Summary

UnderstandOWASP anditsimportance

Understand OWASP and its importance

A popular trend, which started originally with the SANS Institute, is for

organizations to publi sh annual Top 10 lists of each years most common

security vulnerabilities. Since 2003, the Open Web Appli cation Security

Project (OWASP.org) took over this task. The OWASP is a worldwide free

and open community focused on improving the security of application

software that is focused on developing an open source Web appli cation

security community.



Name each ofthe OWASPtop 10vulnerabilities

Name each of the OWASP top 10 vulnerabilities

The OWASP Top 10 Security Flaws are Injection, Cross-Site Scripting (XSS),

Broken Authentication and Session Management, Insecure Direct Object

References, Cross-Site Request Forgery (CSRF), Security Misconfiguration,

Insecure Cryptographic Storage, Failure to Restrict URL Access,

Insufficient Transport Layer Protection, and Unvalidated Redirects and

Forwards.



Understandthe basics ofthevulnerabilitiesand theirimpact

Understand the basics of the vulnerabilities and their impact

SQL injection is a software vulnerability that occurs when data entered by

users is sent to the SQL interpreter as a part of an SQL query. SQL injection

exploi ts security vulnerabilities at the database layer.

By exploi ting the SQL injection flaw, attackers can create, read, modify, or

delete sensitive data.

Cross-site scripting (XSS) is a Web-based security vulnerability in which a

user instead of a Web application is attacked. During such an attack, a

vulnerable Web application is hacked to delive r malicious content to

users via script. This content can include HTML or JavaScript code and

appear as a persistent, a reflective or non-pe rsistent, or a DOM-based

attack.

The Web is inherently connectionless and stateless and developers rely

on data sent to the client and returned with each new request to track the

users session. Improper handling of such information can lead to an

attack where an attacker alters session data and impersonates the sess ion

data of another user, hijacking the users session. After attackers know

where this information is stored, they simply alter the information insuch a way that the server will vi ew it as the valid session of another user

whose session is hijacked.

Insecure Direct Object Reference is a security vulnerability that occurs

when a developer accidentally or due to negligence happens to create a

URL or form parameter with a reference to an object, such as a fi le,

directory, database record, or a key, which is confidential to the

organization.

CSRF is a malicious attack where the attacker exploi ts the users Web

browser to execute undesired actions on behalf of the use r. These

actions include transferring funds, changing passwords, and purchasing

items using online shopping.

Inadequate operational practices can lead to security compromises using

exploi ts of security features or of known vulnerabilities. Improper

permissions may allow mali cious users to perform actions that they

shouldnt. A few misconfiguration types, such as missing patches,

misconfigured or disabled security features, default accounts,




36/57

unnecessary or unused services or fe atures, and administrative

backdoors, can render a Web application vulnerable to attacks.

Insecure storage is also a common vulnerability. Trusted users within the

organization network can steal unencrypted sensitive data in temporary,

hidden, and registry files. Attackers that exploi t another OWASP Top 10

vulnerability can also steal this data. To avoid, this you follow steps such

as encrypting sensitive data, ensuring that encrypted data cannot be

overwritten, and keeping secrets from even trusted employee s.

Although, cryptography is an e ffective way of protecting data, it can be

used incorrectly. Developers select inappropriate ciphers or weak

algorithms such as MD5, SHA-1, and RC3 to encrypt data.

Attackers can also use a technique called forced browsing to bypass Web

site security and access data source fil es and source code directly. To

prevent forced browsing, you should use ACLs, remove unnecessary files

from Web accessible directories, use virtual directories for Web access

and separate secure directories data, and define the li st of file types

available for remote reading.

Sensitive data can also be leaked when applications transmit it across

networks. To ensure security during the communication of sensitive data,

you should secure the channel betwee n communication end points using

technologies such as SSL/TLS and IPSec.

Unvalidated forwards can allow a mali cious user to spoof your site. The

malicious user provides the victim with what looks like a link to your site

but actually redirects the victim to a malicious location. Many

authentication systems use redirection to return a requester to an

authorized URL after login, so the user may not notice that the site is

incorrect.

The two threats from the 2007 OWASP Top 10 list are malicious file

execution and information leakage and improper error handling.

Code vulnerable to remote fil e inclusion (RFI) allows attackers to include

hostile code and data, resulting in devastating attacks, such as total server

compromise. Malicious f ile execution attacks affect PHP, XML, and any

framework that accepts filenames or files from users.

Disclosing information in error messages is often done because it helps

normal users to fix errors and help developers fix various problems.

Applications should handle error messages with a lot of restrictions.

Improper error handling can provide information that can be used for

attacking a system. To prevent information leakage one must segregate

information based on some pre-defined criteria. You should determine i n

advance about which information is safe for disclosure and which

information needs protection.






37/57

Security Principles

Security Principles

Module Overview

This module will help you understand key security principles and

recognize the importance of incorporating these principles within

your software development lifecycle.

Module Objectives


Understand and incorporate key security principles.Define Layered Security / Defense in Depth.Define segmentation.Define structural security.

Narration:This module will help you understand key security principles and the importance ofincorporating these principles within your software development lifecycle. The module will firstintroduce you to incorporating security into your software development process. Then, it willintroduce defense in depth as a strategy to protect information technology resources anddata. This module will further describe different ways to segment data, the importance ofstructural security in an organization, and various principles of information security. Finally, themodule will help you recognize the need to test for security vulnerabilities.

Structural Security

Structural security is security that has been baked into the very foundation of an applications

architecture.

Apply simple, structural security, whenever possible.General examples include concrete buildi ng material.Technical examples include a hardened server or an environment with unused fe atures and

services removed.

Narration:Structural security is the very foundation of an applications architecture. For example, usingconcrete as a building material gives a structural security benefit against the threat of fire.

Another example might be including only one entrance or exit in an airport parking lot tomonitor cars. Often, incorporating structural security makes an application simpler and easierto maintain albeit sometimes at the expense of features.

One good example of employing structural security in software is turning off unused servicesand removing unnecessary files from a host operating system. This minimizes the attacksurface and exposes less functionality that may be attacked.




38/57

Principle of Least Privilege

To help maintain security, all entities (pe ople, processes, devices) should be assigned the

fewest privile ges consistent with their assigned duties and functions.

Definition

Each user, program, and program component operates using the fewest privi leges required forproper functionality.

Rationale

Limits damage from an accident, an error, or an attack.Reduces interactions among privileged programs.Limits successful attackers to only assume the authority associated with the compromised

account.

Examples

Users get only the privileges they requi re to do their job.Administrators only login with admin privileges when they absolutely need it.Applications only open files with the specific permissions that are required.

Narration:A basic principle in information security says that entities, such as people, processes, anddevices, should be assigned the fewest privileges consistent with their assigned duties and

functions. For example, the restrictive "need-to-know" approach denies access to all resourcesby default, then explicitly grants privileges as they are needed. Applying this principle to acorporate network would result in all data being off-limits except to specific users or groups.

In contrast, a less-restrictive strategy opens all systems and closes access as required. Forexample, allowing employees access to all systems except human resources and accounting,which is limited to employees in those departments. This is not an ideal approach as it requiresthe blacklist to be regularly updated any time new users are added, otherwise those users may

be implicitly granted access that they should not have.

Abiding by the principle of least privilege limits the damage from an accident, an error, or anattack and reduces interactions among privileged programs. Successful attackers can onlyassume the authority associated with the compromised account.

Some common examples of least privilege include giving users only the privileges they requireto do their job, implementing a policy that requires administrators to only log in with admin

privileges when they absolutely need it, and allowing applications to only open files thatcontain the required permissions.

Test Everything

It is important to perform security testing to catch improper design and coding practices that may

have been missed earlier in your deve

Documents

Fundamentals of Application Security