Application Security Fundamentals

Application Security Fundamentals
Page 1 of 61
Print

Table of Contents:
Course Overview and Objectives
Introduction
Introduction What is security? What is software security? Cost of Security Defects
Threat Terminology
Module Summary
Challenge Security Misconceptions

Challenge Security Misconceptions The Changing Attack Profile Functional Testing versus Security Testing Security Bugs All Software Has Bugs Patches Do Not Guarantee Security Internal Threats Module Summary
OWASP
OWASP Introduction to OWASP
Cross-site Scripting (XSS)

Key Concepts of Cross-site scripting (XSS) Impact of XSS Identifying XSS Flaws Preventing XSS Flaws
SQL Injection
Key Concepts of SQL Injection Preventing SQL Injection
Insecure Direct Object Reference

Key Concepts of Insecure Direct Object Reference Directory Traversals Addressing Directory Traversal Issues
Cross-Site Request Forgery (CSRF)

Key Concepts of Cross-Site Request Forgery (CSRF) Executing CSRF Attacks Preventing CSRF
Malicious File Execution

Malware Malicious File Execution
Information Leakage and Improper Error Handling

https://elearning.securityinnovation.com/veracode/file.php/35/moddata/scorm/187/CourseFi... 2/8/2010
Page 2 of 61
Preventing Information Leakage and Improper Error Handling
Broken Authentication and Session Management

Session Hijacking Preventing Session Hijacking Example of Session Fixation
Poorly Implemented Cryptography Insecure Communication

Secure Sockets Layer and Transport Layer Security (SSL and TLS) Internet Protocol Security (IPSec)
Failure to Restrict URL Access

Module Summary
Security Principles
Security Principles Structural Security Principle of Least Privilege Test Everything Module Summary
Security Goals and Controls

Authentication
Authentication Authentication Considerations Authorization
Authorization Considerations
Authorization Considerations Module Summary
Security in the SDLC

Security in the SDLC Establishing Security Requirements Categorizing Threats Prioritizing Threat Mitigation Developing Secure Code Overview of Security Testing Testing for Specific Types of Vulnerabilities Leveraging Security Testing Tools Stop and Think! Module Summary
Page 3 of 61
Course Overview and Objectives

Just like functionality, performance, and reliability, security 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 will be able to: Understand the attacker mindset and what is at risk. Recognize the importance 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 principles. Understand key security goals and controls. Understand how security fits into the software development life cycle (SDLC).
Just like functionality, performance, or reliability, security is another crucial component of an Narration: 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 is essential to enable you to help your organization build secure software. This course will teach you the activities that an organization needs to undertake to ensure that the software it develops can withstand malicious attacks. This course assumes that you possess basic computer skills and a basic knowledge of the software development process. By the end of this course, you will be familiar with the main characteristics of a secure software development lifecycle and the activities that your organization should perform to develop secure software. Furthermore, you will recognize the need to address software security in your everyday work.
Introduction
Introduction
Page 4 of 61
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 software 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.
This module will help you understand the importance of designing and maintaining software Narration: 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 software security failures can lead to meaningful business risks. The module defines threat terminology and helps you understand how threats are evaluated using threat modeling techniques. Also demonstrated are guidelines on identifying attacks and understanding the attackers motivations. Finally, the module explains why a consistent assessment methodology is required to ensure secure software implementations.
What is security?
Information security seeks to protect the confidentiality, integrity, and availability of Narration: protected information and systems. These three principles of information security are called the CIA triad. Confidentiality means that private or proprietary information is protected from unauthorized disclosure. Integrity refers to the need to protect information from being modified or deleted by unauthorized users. Maintaining availability of protected systems ensures that information and business functions will be reliably accessible.
What is software security?
Page 5 of 61
Software security is the design and implementation of application functionality intended to ensure the confidentiality, integrity, and availability of protected information and systems. Software security must align with: Confidentiality Integrity 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.
Software security is the design and implementation of application functionality intended to Narration: ensure 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 primarily focuses on the protection of an organizations servers and computer infrastructure with the help of firewalls and intrusion-detection techniques. These mechanisms control the flow of data between networked systems. On the other hand, software security focuses on protecting information and resources made accessible by applications and programs running on computer systems. A good software security policy can trace its roots to larger corporate risk-management policies. Software security is most effective when developed with the framework of an overall security and risk-management strategy adopted by your organization.
Cost of Security Defects
Page 6 of 61
The cost of removing a security vulnerability increases exponentially 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 it after deployment. Removing a defect even earlier, during design, is far cheaper than removing it during testing.
The longer it takes to find a security bug, the more money is spent fixing it. Imagine that a Narration: security bug is found in a piece of popular desktop software; it would be expensive to fix. There is 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 their customers, and provide them with the patch. The patch must be tested and deployed. If you are interested in reducing your total cost of securing your application, make it a point to discover security vulnerabilities as quickly as possible in your application. Do not wait until your customer discovers a vulnerability, or falls victim to a security breach, before you fix it.
Threat Terminology
Page 7 of 61
Module Summary
Page 8 of 61
Understand the importance of software security
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.
Understand the cost of security defects
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 the initial stage is much less compared to finding bugs at later stages. You may click each objective above in order to learn more. Click here to go over this section again.
Understand threat and risk management terminology
Understand threat and risk management terminology To get a deeper insight of software security, you need to be wellversed 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 identify the impact of a problem if it were to occur. You may click each objective above in order to learn more. Click here to go over this section again.
Page 9 of 61
Distinguish between types of attackers and their motivations
Distinguish between types of attackers and their motivations In order to conduct proper threat modeling and design appropriate defenses, it is important to understand the different types of attackers, recognize their motives, and appreciate their skill sets. Not all software requires the same level of security, so accurate asset identification and threat modeling is essential to a well-designed risk management plan. You may click each objective above in order to learn more. Click here to go over this section again.
Page 10 of 61

Module Overview This module highlights common misconceptions around application security. We will explain 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 After completing this module you will be able to: Describe common security misconceptions. Explain how to avoid common security misconceptions.
This module highlights common misconceptions around application security. We will explain Narration: each of these misconceptions, explaining the risks these misunderstandings can pose as well as steps 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 firewalls and antivirus software. The truth is that security is a software problem and network insecurities usually result from flaws in applications running on the system or poor configurations. It is estimated that over 70 percent of attacks against a companys network are at the Application Layer, not at the system or network layer.
Page 11 of 61
Most people tend to think of security as a network problem and the common answer to Narration: security 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 network insecurities, result from flaws in applications running on the system or because of poor configurations. According to Gartner, over 70 percent of attacks on a companys network are at the Application Layer, not at the system or network layer. Network security does little to protect sites from an application-layer attack. For example, a properly constructed and encrypted SSL Web request bypasses the firewall and is completely unseen by a Network Intrusion Detection System. With that said, if attackers gain access through 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 an attacker will attempt to penetrate the layer thats appropriate for the asset theyre trying to hack.
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 software supposed to do?" Security Testing: Security testing involves verifying that the application does not do what it is not supposed to do. It includes applying inputs and verifying that no bad things occur. Security testers ask "What is the software not supposed to do?"
Development teams have been performing functional testing for decades and the process is Narration: pretty well entrenched. Usually, we have a test plan that tells us what the application is supposed to do. Say, for example, our test plan tells us to apply input A and that the application should generate output B. As a functional tester, thats what we doapply A, watch for B and when we see it, we mark the test case as passed. What we are doing here is verifying that the application did what it was supposed to do. But this is both too much and not enough for security testing. Its too much because security testers dont bother with what the application is supposed to do. Its not enough because we should also be concerned with what the application is not supposed to do! In other words, when we apply input A, we should not care about output B that is supposed to occur. 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.
Page 12 of 61
Security Bugs
Security bugs are much harder to spot than functional bugsthey often have no visible (to the human eye) behavior. To find security bugs: Think about side effects and what sensitive data might be exposed to. Think backwardsthat is, instead of thinking what should happen, we need to think about what shouldnt happen.
When testing for security bugs, keep in mind that these types of bugs can be much harder to Narration: spot than a functional bug. They are often the result of side effects or the interactions of multiple bugs that result in an exploitable outcome. Security testing requires you to think first about the possible threats to an application, the undesirable outcomes, and then progress from the threat to the attacks that could realize that threat.
All Software Has Bugs
All software will have bugs, even the best developers make mistakes. Some of these bugs will inevitably result in security vulnerabilities. Factor time into your projects to think specifically about security. If you conduct assessments of security early, find security bugs before its too late, you may save a lot of time and money.
Even the best developers make mistakes. Practically speaking, all software has bugs, and Narration: some of those bugs, regardless of the security controls used, will result in a security vulnerability that may cause harm to your users or data. It is a common fallacy that security features will protect against all security problems. A security feature is typically designed to protect against one specific attack such as encryption protecting against eavesdropping. Encryption cannot protect against SQL injection, buffer overflows, and other very common vulnerabilities. Consider vulnerability assessments as a benefit to application development. U.S. $1 spent up front on vulnerability assessment saves U.S. $10 during development and U.S. $100 after release. Finding vulnerability in your design means that you have the opportunity to redesign more securely. However, if you find vulnerabilities during the development phase, you need to spend time and money on changing the design, which will have a cascading impact on your implementation. If you find vulnerabilities during testing or after the software has been released, you need to change the design and rewrite code to close the vulnerabilities.
Page 13 of 61
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 vulnerability 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.
Whether you are modifying, fixing, or patching code, all maintenance tasks must be evaluated Narration: for risk so that maintaining your application does not introduce security flaws that were not there prior to maintenance. Patches can fix security vulnerabilities and other bugs, and can improve 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 problems in your software that you do not know about yet. In addition, patches do not always address the root cause of problems and may actually introduce new functional or security bugs.
Internal Threats
Page 14 of 61
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 insiders. Internal attackers have far more access to data and systems than outsiders. The clueless and careless insiders 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.
Internal sources of threats cannot be ignored because its estimated that 29 percent of all Narration: attacks 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 result they can cause much more damage. They can directly steal data from the data store and transport that data out of the organization. Common methods for transporting data are small USB flash memory devices or sending the outbound data encrypted as an SSL transaction using the fast network bandwidth. The data can even be chunked into small files to not set off the suspicious 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 treat internal data feeds to an application as not trusted. Remember that even the most trusted user can be a hacker!
Module Summary
Page 15 of 61
Describe common security misconceptions
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 firewalls are good enough to protect applications. However, these too have their shortcomings and cannot prevent application-level attacks. You may click each objective above in order to learn more. Click here to go over this section again.
Explain how to avoid common security misconceptions
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 look out for behaviors that should not happen. Additionally, you should be wary of internal attacks and design your 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. You may click each objective above in order to learn more. Click here to go over this section again.
Page 16 of 61
OWASP
OWASP
Module Overview Open Web Application Security Project (OWASP) is an opensource application security project. This module will help you understand what OWASP is all about. Module Objectives After completing this module you will be able to: Understand OWASP and its importance. Name each of the OWASP top 10 vulnerabilities. Understand the basics of the vulnerabilities and their impact.
This module will help you understand what Open Web Application Security Project (OWASP) Narration: is. First, you will be introduced to what OWASP stands for and why it is important in the software development lifecycle. Then, this module will provide details about the top 10 vulnerabilities listed under OWASP and describe how these vulnerabilities can evolve over time as new attacks are discovered. By the end of this module, you will know about the basics of vulnerabilities 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.
A popular trend, which started originally with the SANS Institute, is for organizations to Narration: publish annual Top 10 lists of each years most common security vulnerabilities. Since 2003, the Open Web Application Security Project (OWASP.org) has published such a list for Web application security. The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of Web applications. Security experts from around the world gather to share their expertise with each other and come up with the top 10 security vulnerabilities of the year. These vulnerabilities, collated as the OWASP Top Ten, provide a powerful awareness document for Web application security and represent 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 software development culture within your organization into one that produces more secure code.
Page 17 of 61
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 applications. In XSS attacks, the victim is the user and not the application. In XSS attacks, malicious content is delivered to users using JavaScript. The 3 type of XSS vulnerabilities are: Persistent Reflective (non-persistent) DOM-based
As the name suggests, Cross-site scripting (XSS) is a Web-based security vulnerability Narration: in which a user instead of a Web application is attacked. During such an attack, a vulnerable 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, a reflective 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 account Spread Web worms Access browser history and clipboard contents Control the browser remotely Scan 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.
When attackers succeed in exploiting XSS vulnerabilities, they can gain access to Narration: account credentials. They can also spread Web worms or access the users computer and view the users browser history or control the browser remotely. After gaining control to the victims system, attackers can also analyze and use other intranet applications.
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: JavaScript VB Script
Page 18 of 61
ActiveX HTML Flash Be suspicious any time user-provided input is echoed to the page, such as from: Form input Reverse DNS lookup Hidden tags
An XSS flaw is likely to occur if the input data coming to Web servers is not validated Narration: at 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 script that 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 and not 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.
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 their respective URL encoded equals). HTMLEncode all user input returned as part of HTML. Convert all user input to a single character encoding before parsing.
To prevent XSS vulnerabilities, you should URLEncode all user input that is returned Narration: as part of URLs. This will convert ?, &, /, <, >, and spaces to their respective URL encoded equals. 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 encoding before parsing. This applies to Single/Double Hex Encoding, Unicode Encoding, and UTF-8 Parsing.
Page 19 of 61
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. Attackers provide specially crafted input data to the SQL interpreter and trick the interpreter to execute unintended commands. SQL injection exploits security vulnerabilities at the database layer. By exploiting the SQL injection flaw, attackers can create, read, modify, or delete sensitive data.
SQL injection is a software vulnerability that occurs when data entered by users is Narration: sent to the SQL interpreter as a part of an SQL query. SQL injection exploits security vulnerabilities at the database layer. By exploiting the SQL injection flaw, attackers can create, read, modify, or delete sensitive data. Attackers utilize this vulnerability by providing specially crafted input data to the SQL interpreter in such a manner that the interpreter is not able to distinguish between the intended commands and the attackers specially crafted data. The interpreter is tricked into executing unintended commands.
Preventing SQL Injection

In order to prevent or mitigate SQL injection vulnerabilities: Use input validation for length, type, syntax, and business rules. Grant least privileges to those with database permissions. Use strongly typed parameterized queries. Show care when using stored procedures.
SQL injection can be prevented if you adopt an input validation technique in which Narration: user input is authenticated against a set of defined rules for length, type, and syntax and also against business rules. You should ensure that users with the permission to access the database have the least privileges. Additionally, do not use system administrator accounts like sa for Web applications. Also, you should always make sure that a database user is created only for a 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 SQL injection. However, be careful as they can be injectable (such as via the use of exec() or concatenating arguments within the stored procedure).
Page 20 of 61
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 objects and exploit them. Avoid exposing direct references. If they must be used, perform an authorization check.
Insecure Direct Object Reference is a security vulnerability that occurs when a Narration: developer 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 access to other confidential objects and view or modify them. The best protection is to avoid exposing direct object references to users by using an index, indirect reference map, or another indirect method that is easy to validate. If a direct 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 escape Application Directory by: using / or \ to access root directory using .. to access parent directory manipulating symbolic links (i.e. shortcuts)
Page 21 of 61
Directory traversals can happen when a Web application accepts a filename from the Narration: user but doesnt validate that the filename does not allow the user to access unintended locations in the file system.
Addressing Directory Traversal Issues
In order to prevent or mitigate directory traversal: Examine code against a user-specified file Always use Explicit paths Define application-specific MYAPP_PATH Use regular expressions to opt in known good paths For example: ^[cd]:(?:\\\w+)+\\\w{1,32}\.(txt|jpg|gif)
To avoid directory traversal, you should examine application code against a userNarration: specified file. You should avoid relative or default paths. In addition, you should never use the environment variable path for locating files because they can be changed and cannot be relied upon. Therefore, you should always define explicit, applicationspecific paths, such as MYAPP_PATH. To do this, you can use a regular expression that will allow you to use the files present on paths already known, verified, and secured by you. Note the sample expression displayed on the screen. In this expression, the displayed path is alphanumeric, which allows the application to accept txt, jpg, or gif files from the C or the D drive of the server hosting the application.
Page 22 of 61
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 funds Changing passwords Purchasing items using online shopping
Cross-Site Request Forgery (CSRF) is a malicious attack that tricks the users Web Narration: browser 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 users browser, perhaps with a hostile Web site, when the user is checking an online bank account, the attacker can change the users transaction password to control the users actions and transfer funds to the attackers account.
Executing CSRF Attacks
Page 23 of 61
CSRF attackers use the functionalities of the victims 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, if an attacker exploits the CSRF vulnerability at this stage, the Web application is not able to distinguish between a valid action performed by the user or a malicious action initiated by an attacker.
To exploit CSRF vulnerability, the attacker uses the functionality of the victims Web Narration: browser. When the victim is accessing a Web site using his login ID and password, the victims 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 action on this Web site. Since the user was authenticated by the Web site, if an attacker exploits the CSRF vulnerability at this stage, the Web application is not able to distinguish between a valid action performed by the user or a malicious action initiated by an attacker.
Preventing CSRF
Page 24 of 61
The most common defense is to append challenge tokens to each request. These challenge tokens must be associated with the users session. Advantages of using challenge tokens are: Attackers will not be able to provide a valid token of their own to utilize within the attack. Developers can ensure that the request is valid and not coming from a source other than the user.
The most common method to prevent CSRF attacks is to append challenge tokens to Narration: each request and associate them with the users session. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user.
Page 25 of 61

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 is reached
Malware is one of the most common malicious attacks that can be used for breaching Narration: application security. Attackers having access to upload or attach arbitrary files can spread malware from their computers to trusted systems. Then, remote or local users of the application may inadvertently execute these files. There are three major types of malwares Worm, Virus, and Trojan Horse. A Worm is a self-propagating program that takes advantage of either a vulnerability in an operating system or a common software to breach a system and start executing malicious codes in the system. The Worm doesnt stop here, it then searches for other systems with some vulnerability and repeats the process to spread itself. Worms can spread 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 is moved to another system and executed, other files on that system become infected with 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 Trojan Horse purports to be a beneficial program. However, it harbors malicious functionality such as a keystroke logger for capturing passwords or remote access that will allow an attacker 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 an electronic greeting card.
Page 26 of 61
When user input is used to open files 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 unfiltered user input to craft a filename or an OS exec input. Dont allow user input to create server-side script or include files.
Malicious code execution can be prevented by following some guidelines. You should Narration: never expose file identifiers to a user such that they become part of user input and can be easily modified by them. Exposing file identifiers can also cause information leakage by allowing the user select the filename opened by the application. Moreover, if the application executes commands or scripts contained in the file, this can lead to the more serious malicious code execution. Suppose user input is part of an OS shell or an exec command. Then the user can specify commands to execute. Therefore, you should always filter user input going into system(), StartProcess(), java.lang.Runtime.exec(), System.Diagnostics.Process.Start() or similar APIs. Another malicious code execution is an include file injection. An include file injection occurs when the user is able to specify a filename as input that gets included into a running script under PHP. Script injection occurs when the user is able to specify input that is interpreted by the server-side scripting engine in PHP or ASP.
Page 27 of 61

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 information 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 provide Application/platform identification information. Error encountered at line 123 in file this_is_a_weak_app.asp can provide application implementation details. Invalid password supplied for user id xxxxx. can disclose accurate user ids.
Disclosing information in error messages is often done because it helps normal users Narration: to fix errors and help developers fix various problems. Examples of error messages that are likely to disclose information are ODBC error messages, authentication error messages, and others. Applications should handle error messages with a lot of restrictions. Improper error handling 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.
Page 28 of 61
To prevent information leakage, one must segregate information based on some preNarration: defined criteria. You should determine in advance about which information is safe for disclosure and which information needs protection. The best way to determine the level of information confidentiality is by thinking from an attackers perspective and determining what the attacker can do with the information. Even while developing error-handling messages for an application you should use a standard error response for all sensitive data errors. Just mention the macro problem, such as An error has occurred accessing the database.
Page 29 of 61
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 valid session ID. Attacker tries to steal session information from the cookies stored in the users computer. Guess a predictable session ID.
The Web is inherently connectionless and stateless and developers rely on data sent to Narration: 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 session data of another user, hijacking the users session. After attackers know where this information is stored, they simply alter the information in such a way that the server will view it as the valid session of another user whose session is hijacked. Session hijacking can be done in several ways. For example, an attacker can intercept the 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 stored on the users computer. Finally, if session IDs are predictable an attacker could guess a valid one.
Preventing Session Hijacking
Page 30 of 61
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.
To develop a secure application, you should restrict the instances of session hijacking Narration: 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 and referenced 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 of identifying information, such as the IP address of the user. This will make it more difficult 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 also expire after a set period of inactivity. This ensures that an attacker will not be able to replay a valid session at a later stage.
Example of Session Fixation
Page 31 of 61
Lets observe an example where an attacker induces a client to establish a session Narration: with the target software using a session identifier provided by the attacker. Analysis indicates that the attacker either has used a malicious link or has leveraged on an earlier attack, such as XSS. As soon as user requests for a specified application with a valid session ID, the application authenticates the user. However, the attacker already knows the same session 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 either relies on client-generated session identifiers or maintains the same session identifiers after privilege elevation. How to prevent such instances? To prevent session hijacking it is important to invalidate the unprivileged session ID and provide a new session ID after authentication. It is also important to ensure correct logout, password management, and timeout functions to help mitigate various instances of session fixation and hijacking.
Page 32 of 61
Poorly Implemented Cryptography
Page 33 of 61
Insecure Communication
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.
SSL/TLS is commonly used to secure the channel between a browser and a Web Narration: server. It is application independent and allows protocols like HTTP, FTP, and Telnet to be layered 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 are exchanged, it uses a number of ciphers including RC2, RC4, IDEA, DES, and tripleDES.
Internet Protocol Security (IPSec)
Page 34 of 61
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 confidentiality 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 the developer. It does not provide user-level authentication. It uses the philosophy that only the OS configuration needs to change and not individual applications.
IPSec, which is mostly used in Virtual Private Networks (VPNs), provides a transport Narration: level secure communication solution that can be used to secure the data sent between two computers. It ensures confidentiality and authentication of all network traffic at the IP level. Another benefit of IPSec is that it can provide some security services in the background with no impact on user or the developer. Also, it does not provide userlevel authentication and uses the philosophy that only the OS configuration needs to change and not the individual applications.
Page 35 of 61
Failure to Restrict URL Access
Page 36 of 61
Module Summary
Page 37 of 61
Understand OWASP and its importance
Understand OWASP and its importance A popular trend, which started originally with the SANS Institute, is for organizations to publish annual Top 10 lists of each years most common security vulnerabilities. Since 2003, the Open Web Application 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 application security community. You may click each objective above in order to learn more. Click here to go over this section again.
Name each of the OWASP top 10 vulnerabilities
Name each of the OWASP top 10 vulnerabilities The OWASP Top 10 Security Flaws are Cross-site Scripting (XSS), Injection Flaws, Malicious File Execution, Insecure Direct Object Reference, Cross-site Request Forgery (CSRF), Information Leakage and Improper Error Handling, Broken Authentication and Session Management, Insecure Cryptographic Storage, Insecure Communications, and Failure to Restrict URL Access. You may click each objective above in order to learn more. Click here to go over this section again.
Page 38 of 61
Understand the basics of the vulnerabilities and their impact
Understand the basics of the vulnerabilities and their impact 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 deliver malicious content to users via script. This content can include HTML or JavaScript code and appear as a persistent, a reflective or nonpersistent, or a DOM-based attack. 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 exploiting the SQL injection flaw, attackers can create, read, modify, or delete sensitive data. 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 file, directory, database record, or a key, which is confidential to the organization. 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 funds, changing passwords, and purchasing items using online shopping. Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file 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 in advance about which information is safe for disclosure and which information needs protection. 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 session data of another user, hijacking the users session. After attackers know where this information is stored, they simply alter the information in such a way that the server will view it as the valid session of another user whose session is hijacked.
Page 39 of 61
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 After completing this module you will be able to: Understand and incorporate key security principles. Define Layered Security / Defense in Depth. Define segmentation. Define structural security.
This module will help you understand key security principles and the importance of Narration: incorporating these principles within your software development lifecycle. The module will first introduce you to incorporating security into your software development process. Then, it will introduce defense in depth as a strategy to protect information technology resources and data. This module will further describe different ways to segment data, the importance of structural security in an organization, and various principles of information security. Finally, the module 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 building material. Technical examples include a hardened server or an environment with unused features and services removed.
Page 40 of 61
Structural security is the very foundation of an applications architecture. For example, using Narration: concrete 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 to monitor cars. Often, incorporating structural security makes an application simpler and easier to maintain albeit sometimes at the expense of features. One good example of employing structural security in software is turning off unused services and removing unnecessary files from a host operating system. This minimizes the attack surface and exposes less functionality that may be attacked.
Principle of Least Privilege
To help maintain security, all entities (people, processes, devices) should be assigned the fewest privileges consistent with their assigned duties and functions. Definition Each user, program, and program component operates using the fewest privileges required for proper 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 require 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.
Page 41 of 61
A basic principle in information security says that entities, such as people, processes, and Narration: devices, 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 resources by default, then explicitly grants privileges as they are needed. Applying this principle to a corporate 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. For example, 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 requires the 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 an attack and reduces interactions among privileged programs. Successful attackers can only assume the authority associated with the compromised account. Some common examples of least privilege include giving users only the privileges they require to 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 that contain 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 development process: Never assume that security controls are effective until you can validate them with thorough testing. Most security vulnerabilities will not be discovered during normal application use. Allocate time for dedicated security testing within your project timeline. Always test applications and application components, both in isolation and in the environment where the application is deployed.
Since many vulnerabilities are caused by mistaken assumptions by programmers or by Narration: mistakes in the code, it is important to test all code for security vulnerabilities. An application or application component should not be assumed to be secure until security controls have been thoroughly tested. Typical application use cases or traditional feature testing will not find most security vulnerabilities. Security testing must be performed in order to find security vulnerabilities, so it is important to allocate dedicated time for security testing during the testing phase of the software development cycle. It is important to test for security vulnerabilities both in isolation and in the environment the application is designed to run in. It is common for a security vulnerability to be exploitable only when the application is interacting with the operating system and other backend services.
Module Summary
Page 42 of 61
Understand and incorporate key security principles
Understand and incorporate key security principles Security is a process of protecting information. So security principles should be incorporated within the software development lifecycle from the very beginning of the project. Incorporating these principles, early within the development lifecycle, dramatically improves the security of your application. Key security principles are least privilege, default deny, and input or data validation. The least privilege principle says that entities (people, processes, devices) should be assigned the fewest privileges consistent with their assigned duties and functions. The default deny principle states that access to resources and all application input should be denied unless specifically permitted. Use input and data validation to help prevent attacks based upon maliciously malformed data sent to your application over the Internet, through its UI, through corrupted files, or any other input stream your application can accept. You may click each objective above in order to learn more. Click here to go over this section again.
Define Layered Security / Defense in Depth
Define Layered Security / Defense in Depth Layered Security, or Defense in Depth, is the strategy of using several concurrent methods, such as point security solutions, filtering systems, and monitoring strategies, to protect information technology resources and data. It addresses security vulnerabilities in personnel, technology, and operations for the duration of the systems lifecycle. Layered security makes it more difficult and time consuming for an attacker to mount an attack and limits what the attacker can access with each successful penetration. You may click each objective above in order to learn more. Click here to go over this section again.
Page 43 of 61
Define segmentation
Define segmentation Segmentation is the practice of separating data from logic, segmenting data by privilege, and segmenting applications from environment to improve security. A common example of segmenting data from logic is housing data in a database on a non-publicly accessible system and configuring the Web root of your Web server on a partition separate from the operating system installation. The other way of segmenting data is by privilege. Segmenting data by privilege separates data by the authorization level required to access it. Database tables, Web folders, and configuration files are potential areas where privilege based segmentation could be applied. An application can also be segmented from its environment. This confines the application to a safe space where its access to system resources is tightly constrained. You may click each objective above in order to learn more. Click here to go over this section again.
Define structural security
Define structural security Structural security is the very foundation of an applications architecture. For example, using concrete as a building material gives a structural security benefit against the threat of building collapse. Another example might be of including only one entrance or exit in an airport parking lot to monitor cars. Often, incorporating structural security makes an application simpler and easier to maintain albeit sometimes at the expense of features. One good example of employing structural security is turning off unused services and removing unnecessary files from a host operating system. This minimizes the attack surface and exposes less functionality that may be attacked. You may click each objective above in order to learn more. Click here to go over this section again.
Page 44 of 61

Module Overview Information assets and security go hand in hand. An organizations information assets are subject to security threats. Therefore, every organizations goal is to employ the best security system to protect their information assets from such threats. To develop secure systems, organizations need to define security goals and controls. Module Objectives After completing this module you will be able to: Explain the importance of the CIA triad. Explain the purpose of authentication and authorization. Explain the importance of error and exception handling. Explain the purpose of monitoring and logging. Explain the purpose of cryptography and encryption. Describe database authentication and controls.
Often, an organizations information assets are subject to security threats. Therefore, every Narration: organizations goal is to employ the best secure systems to protect their assets from these threats. An important step in developing security systems is to define security goals and controls. This module will help you recognize the main security goals and features that you might require while developing a secure system. This module will first explain the importance of the security goals of confidentiality, integrity, and availability. The module will go on to explain the purpose of authentication, authorization, and access controls. Finally, the module will provide information about the purpose of error and exception handling, monitoring and logging, cryptography and encryption, and database security.
Authentication
Authentication
Page 45 of 61
The authentication process verifies the identity of an entity. The entity could be a computer or a computer user. Trust is established based on the quality of your authentication implementation and the strength of the entity-provided credentials. Common authentication mechanisms include: Passwords X.509 Certificates Kerberos Tickets Smart Cards Tokens Biometrics
Forming goals is not enough to ensure software security. You also need to have Narration: various technical controls to manage security threats. That is why authentication, authorization, and access control are present in many types of applications. Authentication verifies the identity of a computer or a computer user. Commonly, the authentication process involves entering and verifying a username and a password. However, authentication can also include other methods of identity verification such as smart cards, retina scans, voice recognition, or fingerprints. There are different types of authentication such as basic authentication, digest authentication, form-based authentication, smart card, biometrics, and digital certificates. Trusting a particular authentication method is based on the quality of implementation and the strength of credentials.
Page 46 of 61
Authentication Considerations
Authentication Considerations Any authentication method could have weaknesses. Authentication mechanisms are often the first target of an attack. Implementing Authentication Use two-factor authentication for added security. Define and test all authentication information for valid format and length.
All authentication methods have weaknesses and can be breached because of poor Narration: implementation. Security vulnerabilities can occur in implementations that include passwords, certificates, or even biometrics. The authentication process is often attacked first because even an unauthenticated user can access the login page of your application. To strengthen the authentication process, you can use two-factor authentication. Two-factor authentication provides added security by simultaneously using two different factors to verify users. In two-factor authentication, a user must know something unique and posses something unique. For example, knowing a password and possessing a hard token to login to a system.
Authorization
Page 47 of 61
The authorization process: Determines and grants rights to an authenticated entity. Often uses Access Control Lists (ACLs) for resource-based authorization. May use LDAP servers to store information about user roles and privilege levels. Common authorization techniques are: Resource-based authorization, such as Access Control Lists (ACLs). Role-based authorization, such as LDAP or Active Directory.
Authorization is the process of determining the rights that should be granted to an Narration: authenticated entity. After the identity of a user is authenticated, an application authorizes a user to perform actions in the system based upon the permissions associated with the authenticated identity or the permissions of the group or role that the identity belongs to. Authorization can also be performed on specific resources, such as a database or a file on the file system. Access Control Lists (ACLs) are a common mechanism by which resource-based authorization is performed on the Windows operating system. Authorization is similar to checking the guest list at an exclusive party or checking your opera ticket. In these cases, the security personnel verify the guests name against the guest list. In this analogy, authentication is checking the ID and authorization is checking that name against the list of allowed guests. Similarly, authorization is often achieved via Access Control Lists (ACLs). You can grant or deny access based on a wide variety of criteria, such as the network address of the client or the time of day. Access control permits and restricts user entry. It behaves like a gate that closes after a stipulated time or a gate that only allows employees to enter the premises of an organization.
Page 48 of 61
Authorization Considerations Use access controls to structurally harden your environment. Keep in mind that thoughtful segmentation will facilitate authorization. Use the principle of least privilege and grant each entity the minimum privileges required for proper business functionality. Scrutinize integration with other components. Define responsibility and examine implementation carefully. Ask yourself, What type of access does my application need? Log files Configuration files Database tables
Access controls help you structurally strengthen your environment. By appropriately Narration: setting access control permissions on your resources, you can reduce the amount of damage an attacker can inflict when exploiting a vulnerability. Use access controls to structurally harden your environment. Thoughtful segmentation will facilitate authorization. Use access controls to implement the principle of least privilege. The principle of least privilege states that you should grant the minimum privileges to the users and roles in your application so that they can accomplish appropriate tasks but are not allowed to do any more. For instance, you may lock down the account that accesses your database so that it only has permissions to read from specific tables rather than have the ability to read, write, and delete any table in the database. If an attacker is able to exploit a vulnerability, such as SQL injection, on your application, access controls on the database will limit the amount of damage that is possible. Scrutinize integration with other components. Define responsibilities and examine implementation carefully. Before designing access controls, analyze the type of access required by each of the roles in your applications.
Page 49 of 61
Module Summary
Page 50 of 61
Explain the importance of the CIA triad
Explain the importance of the CIA triad Information security is the principal of software applications maintaining security goals while handling information. Confidentiality, integrity, and availability are the goals of information security. Confidentiality refers to the privacy of an information asset. The key to integrity is protecting data from modification or deletion by unauthorized parties, and ensuring that when authorized people make changes that shouldnt have been made the damage can be undone. Availability of information means the systems responsible for delivering, storing, and processing information are accessible when needed. You may click each objective above in order to learn more. Click here to go over this section again.
Explain the purpose of authentication and authorization
Explain the purpose of authentication and authorization Various technical controls allow you to manage your security threats. The three techniques authentication, authorization, and access control are generally present in all applications. The authentication process verifies the identity of a computer or a computer user. This process usually involves a username and a password. Authorization and access controls are the processes of determining the rights that should be granted to an authenticated entity. Click each objective to learn more about it. Click here to go over this section again.
Explain the importance of error and exception handling
Explain the importance of error and exception handling Error messages are the potential avenues by which too much information is disclosed to a user or a malicious individual. Inadvertently disclosing internal application details in error messages, provides an opportunity to the attacker. Click each objective to learn more about it. Click here to go over this section again.
Page 51 of 61
Explain the purpose of monitoring and logging
Explain the purpose of monitoring and logging Monitoring and logging is the process of capturing and retaining events. While logging, you record data on application or system activity. You may click each objective above in order to learn more. Click here to go over this section again.
Explain the purpose of cryptography and encryption
Explain the purpose of cryptography and encryption Cryptography disguises messages so that only certain people can identify the actual message. Cryptography is a technological solution for protecting transit data from sniffing and alteration. Cryptography is a predefined procedure to convert plaintext into ciphertext that uses encryption for disguising information. Click each objective to learn more about it. Click here to go over this section again.
Describe database authentication and controls
Describe database authentication and controls Database controls are used to limit what attackers can do. Database controls include logging, denying access to stored procedures, and running the database as a low privileged user. You may click each objective above in order to learn more. Click here to go over this section again.
Page 52 of 61

Module Overview This module will help you understand the root causes of software vulnerabilities and recognize that the cost of fixing these vulnerabilities increases dramatically in later stages of the development lifecycle. You will then be presented with the advantages of following a holistic approach that tackles security at every stage of the software lifecycle. This module will present you with a set of generic security activities that can be performed within your development process to help you, as an organization, reduce your software security risk and produce more secure software. Module Objectives After completing this module you will be able to: Identify the root causes of software vulnerabilities. Recognize that the cost of fixing vulnerabilities increases over time. Comprehend activities that reduce software security risk.
In this module, you will be first introduced to the causes of software vulnerabilities and the Narration: importance of integrating security in the software development lifecycle. Then, this module will present you with a set of generic security activities and best practices that can be followed to help your organization effectively reduce its software security risk.
Establishing Security Requirements
Page 53 of 61
As it marks the beginning of the development effort, the requirements phase is the most appropriate stage to kickoff and setup your security development process. During the requirements phase, you should: Assign a security advisor, either internal to your organization, if available, or from a third-party organization. The security advisor needs to be a software security expert and will be the one validating security activities and deliverables. Assign security leads to the different teams involved in the process, such as the development and testing teams. The responsibility of these security leads will be to drive security efforts within their team. Establish a security bug bar specifying clear-cut security shipping requirements such as ALL vulnerabilities allowing an attacker to access stored or transmitted credit card numbers MUST be remediated before release. Gather security requirements applicable to your software project such as any security standards or regulations it might be subject to including PCI DSS, HIPAA, SOX, GLBA, and Basel II. Identify, acquire, and configure any software security tools needed later in the project, such as configuring your bug tracking system to track security vulnerabilities. Initiate risk assessment to determine quantitative or qualitative value of the risks associated with your software project. Perform an objective evaluation of risks in which assumptions and uncertainties are clearly considered and presented.
A software development lifecycle produces security deliverables at each phase. The Narration: requirements phase is the most appropriate stage to begin your security development process. During this phase, you should: Assign a security advisor who can be someone from your organization or even from a thirdparty organization. The security advisor needs to be a software security expert and will be the one validating security activities and deliverables. Assign security leads to the different teams involved in the process. This includes the development and testing teams who will drive security efforts within their team. Establish a security bug bar clearly indicating the security shipping requirements. For example, ALL vulnerabilities allowing an attacker to access stored or transmitted credit card numbers MUST be remediated before release. Gather security requirements applicable to your software project such as any security standards or regulations it might be subject to including PCI DSS, HIPAA, SOX, GLBA, and Basel II. Identify, acquire, and configure any software security tools needed later in the project, for example, configuring your bug tracking system to track security vulnerabilities. Initiate risk assessment to determine quantitative or qualitative value of risk associated with your software project. An objective evaluation of risk in which assumptions and uncertainties are clearly considered and presented can be performed.
Categorizing Threats
Page 54 of 61
Properly categorizing threats will enable you to identify effective countermeasures to be integrated in your softwares design. A popular method for categorizing threats is the STRIDE approach. STRIDE was developed by Microsoft to classify threats identified while threat modeling. Each type of threat in STRIDE maps to a security property that each software should have to defend against the threat. The provided table defines these threat types and security properties to help you understand how they relate to each other. Threat Spoofing Identity The action of assuming the identity of another user, component, or system. Tampering with Data The action of illegally modifying data. Repudiation The act of denying being the author of a given action. Information Disclosure The action of viewing confidential data without proper authorization. Denial of Service The act of preventing a system from functioning in accordance with its intended purpose. Security Property Authentication The ability of a system to verify the identity of a user, component, or system. Integrity The property of data that has not changed. Note: a system can take two approaches to ensure integrity: enforcing proper access control or tamper-detection. Non-repudiation The ability of a system to ensure that all actions are accounted for and can be traced back to their authors. Confidentiality The property of data that is not viewed by unauthorized parties. Availability The property of data that is accessible to legitimate parties whenever they need it to be.
Threats can be categorized based on the goals and purposes of the attacks. Properly Narration: categorizing threats will enable you to identify effective countermeasures to be integrated in your softwares design. STRIDE is the most common method used for categorizing threats. This method was developed by Microsoft to classify threats identified while threat modeling. Each type of threat in STRIDE is linked to a security property that software should have to defend against the threat. The provided table defines these threat types and security properties to help you understand how they relate to each other.
Prioritizing Threat Mitigation
Page 55 of 61
Because it is usually not possible to address all threats at once, it is important for your organization to be able to prioritize them efficiently. The DREAD methodology, also developed at Microsoft, provides the means for you to quantify the risk introduced by threats or vulnerabilities your organization has identified. DREAD allows you to assign a risk rating to threats by considering the D, R, E, A, and D risk components of a threat. By first rating these components individually and then adding their ratings together, you will be able to rate each threats overall risk. The provided table, taken from Microsofts Patterns and Practices Threat Modeling article, shows an example on how to establish such a rating system. Note that there are other ways to prioritize threats that might be more suitable for your organizations needs. Rating Damage Potential How much damage would be caused if the threat was realized? High (3) The attacker can subvert the security system. Get full trust authorization; run as administrator; upload content. The attack can be reproduced every time. For example, the attack does not require a specific time window to succeed. Medium (2) Low (1)
Leaking sensitive information.
Leaking trivial information.
Reproducibility How easy is it to reproduce the attack?
The attack can be reproduced sometimes. For example, the attack can be reproduced only during a specific time window and when a very particular set of conditions is met.
The attack is very difficult to reproduce. Even with knowledge of the security hole.
Exploitability How easy is it to launch an attack?
By a novice programmer. A novice programmer could craft an attack in a short time.
By a skilled programmer. A skilled programmer could make the attack, then repeat the steps.
By an expert. The attack requires an extremely skilled person and indepth knowledge every time to exploit. Very small percentage of users. For example, users that use an obscure feature of the software.
Affected users How large is the population of affected users?
All users. All users, in the default configuration, key customers. Published information explains the attack. For example, the vulnerability is found in the most commonly used feature and is very noticeable.
Some users. For example, only some users that have a specific non-default configuration are affected. The vulnerability is in a seldom-used part of the product. Only a few users should come across it. It would take some thinking to see malicious use.
Discoverability How easy is it for attackers to find the vulnerability?
The bug is obscure. It is unlikely that users will work out damage potential.
Page 56 of 61
After categorizing threats, you should prioritize them because it is not possible to address all Narration: threats at once. The DREAD methodology helps you to quantify the risk introduced by threats or vulnerabilities your organization has identified. DREAD allows you to assign a risk rating to threats by considering the D, R, E, A, and D risk components of a threat. These components are first rated individually and then their ratings are added together to rate each threats overall risk. The provided table shows an example on how to establish such a rating system.
Developing Secure Code

The development phase is a crucial step in the creation of secure software. 50 percent defects are due to coding errors (Software Security: Building Security In by Gary McGraw (Addison-Wesley, 2006) ISBN: 0-321-35670-5). Developers should be aware of the security peculiarities of each technology they are using to avoid introducing vulnerabilities. Often, specific technologies involve specific secure coding best practices. Some best practices include: Perform input and data validation Do not use insecure APIs Fail securely Protect sensitive data Manage accounts securely Implement proper authorization Follow secure auditing and logging procedures. Perform manual and automated security code reviews to catch security bugs before software is sent out for testing. Note: For guidance on secure coding practices, visit Microsofts Patterns and Practices or the Open Web Application Security Project (OWASP) Development Guide.
Page 57 of 61
The development phase is the most crucial stage in the software development lifecycle Narration: because most coding errors arise at this stage. Developers should be aware of the security peculiarities of each technology they are using to avoid introducing vulnerabilities. Often, specific technologies involve specific secure coding best practices. For example, depending on whether you are developing Web applications, writing native code, following the client-server model, or interacting with backend databases, there are different secure coding best practices you should follow. Generic secure coding best practices that developers should follow include performing input and output validation, not using insecure APIs, failing securely, protecting sensitive data, managing accounts securely, implementing proper authorization, and following secure auditing and logging procedures. To track if such best practices have been properly followed, organizations should perform manual and automated security code reviews to catch security bugs before software is sent out for testing. Static analysis tools can be helpful in auditing source code and detect vulnerabilities during the development phase. These tools scan the applications source code for several bugs. Dynamic scanning is used while the application is running. It helps you to discover bugs and vulnerabilities. On the other hand, manual scanning requires human efforts to discover bugs and vulnerabilities.
Overview of Security Testing

Despite your organizations best effort at designing and developing software securely, vulnerabilities might still be present. Security testing should be performed to uncover these vulnerabilities and provide your organization a chance to remove them before it releases the software to customers or to the production environment. Security testing is very different from traditional functional testing, as it requires different sets of skills and tools. Security testing consists mainly of analyzing the software for the presence of known classes of vulnerabilities. Obviously, to be successful at testing security, software security testers should be aware of these classes of vulnerabilities, their symptoms of failure, and the common methods through which they are discovered. Note: Security test cases should be derived from previously created threat models to ensure that security testing effectively verifies that all applicable threats have been properly avoided or mitigated.
Page 58 of 61
Every organization tries its best to design and develop software securely. Still some Narration: vulnerabilities are left out. To defend against these vulnerabilities, security testing should be performed. Security testing uncovers these vulnerabilities and provides your organization a chance to remove them before it releases the software to customers or to the production environment. Security testing is different from traditional functional testing. Security testing consists mainly of analyzing the software for the presence of known classes of vulnerabilities. To be successful at testing security, software security testers should be aware of these classes of vulnerabilities, their symptoms of failure, and the common methods through which they are discovered.
Testing for Specific Types of Vulnerabilities

Examples of classes of security defects, along with their definition, that software should be verified against: Buffer overflows. A programming error that may result in unauthorized memory access and arbitrary code execution on the victim host. Only affects native code. SQL injection. A type of vulnerability caused by improper inclusion of user-specified parameters into an SQL query that can allow an attacker to change the behavior of the query when it is executed by a backend database. Cross-site scripting. A category of security vulnerabilities common in Web applications that allow code to be injected by malicious Web users into Web pages viewed by other users. Lack of server-side authorization. A vulnerability affecting client-server applications caused by the fact that authorization is performed on the client. By exploiting this type of vulnerability, attackers may illegally access the assets of the system. Weak authentication. A type of flaw that allows attackers to bypass authentication and, therefore, access resources of the system inappropriately. Weak authorization. A class of vulnerability that allows authorization to be bypassed. By exploiting this type of flaw, attackers can potentially elevate their level of privilege by accessing resources that they otherwise would not have access to. Improper use of cryptography. A type of vulnerability caused by the insecure use of cryptographic mechanisms such as encryption and hashing functions. Improper error handling. A category of vulnerabilities that can result in sensitive information being revealed to attackers or the application being in an insecure state.
Page 59 of 61
Security testers need to be familiar with the different categories of software vulnerabilities to Narration: know how to test for them and to be able to spot their presence. Various classes of security defects are as follows: Buffer overflows is a programming error that may result in unauthorized memory access and arbitrary code execution on the victim host. It only affects native code. SQL injection is a type of vulnerability caused by improper inclusion of user-specified parameters into an SQL query that can allow an attacker to change the behavior of the query when it is executed by a backend database. Cross-site scripting is a category of security vulnerabilities common in Web applications that allows code to be injected by malicious Web users into Web pages viewed by other users. Lack of server-side authorization is a vulnerability affecting client-server applications caused by the fact that authorization is performed on the client. Weak authentication is a type of flaw that allows attackers to bypass authentication and, therefore, access resources of the system inappropriately. Weak authorization is a class of vulnerability that allows authorization to be bypassed. Improper use of cryptography is a type of vulnerability caused by the insecure use of cryptographic mechanisms such as encryption and hashing functions. Improper error handling is a category of vulnerabilities that can result in sensitive information being revealed to attackers or the application being in an insecure state.
Leveraging Security Testing Tools

Because security testing often involves monitoring, intercepting, and modifying data in ways that are usually not intended, it requires a specific set of tools. To be efficient at security testing, testers should get help from appropriate security testing tools. These include: Monitoring tools Network sniffers Debuggers and decompilers Web proxies Web application scanners Fuzzers Binary Static Analysis tools
Software testing is an important step in the software development lifecycle that involves Narration: monitoring, intercepting, and modifying data in ways that are usually different from conventional methods. Therefore, it becomes necessary that testers have access to the required security testing tools. These tools include monitoring tools, network sniffers, debuggers and decompliers, Web proxies, Web application scanners, fuzzers, and binary static analysis tools.
Stop and Think!
Page 60 of 61
Prior to the release of a software, it is crucial to ensure that all requirements stipulated earlier in the project are met. What does this mean from a software security perspective? Consider the following activities and reflect on their relevance with respect to your organizations attempt to assess the risk represented by software right before its release: Review of all security deliverables produced so far including security requirements, design documents, threat models, security code review deliverables, and security test plans. Review security bugs and their corresponding fixes. Evaluate the software against the established security bug bar or other security criteria specified at the organizational level. Assess the compliance of software with any applicable standard or regulation. Now, imagine that the software still contains major security vulnerabilities. What would be the possible alternatives for your organization should such a scenario arise? Consider the following possibilities: Release the software as is. Postpone the release. Release the software while disabling components, representing a high risk.
Module Summary
Page 61 of 61
Identify the root causes of software vulnerabilities
Identify the root causes of software vulnerabilities Software vulnerabilities find their roots in improper design and coding practices. However, there are several other areas of the software development lifecycle where an organization can fail to address security. It is crucial to understand these failures in order to justify following appropriate secure development practices throughout the software development process. You may click each objective above in order to learn more. Click here to go over this section again.
Comprehend activities that reduce software security risk
Comprehend activities that reduce software security risk Secure software development is best achieved through a holistic process that prescribes security activities at each phase of the software development lifecycle. These activities include, but are not limited to, gathering security requirements, reducing software attack surface, threat modeling, secure design, following secure coding best practices, security code review, security testing, and security response preparation and execution. You may click each objective above in order to learn more. Click here to go over this section again.

Application Security Fundamentals

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Application Security Fundamentals

Uploaded by

Copyright:

Available Formats

Application Security Fundamentals