Two of the biggest challenges in an organization’s application security strategies are testing and integrating best practices within the application life cycle.
In this E-Guide, readers will learn best practices for testing injection integrating security measures into the application lifecycle.
Application security: Testing for injection
vulnerabilities
By John Overbaugh
One of the most challenging responsibilities of a tester is ensuring the security of a Web application. In this tip, I’ll cover a few steps testers can take to be more effective in testing
for OWASP’s top security vulnerability: injection.
According to the OWASP project:
Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. Attackers trick the interpreter into executing unintended commands via supplying specially crafted data. Injection flaws allow attackers to create, read, update, or delete any arbitrary data available to the application. In the worst case scenario, these flaws allow an attacker to completely compromise the application and the underlying systems, even bypassing deeply nested firewalled environments.
The goal of an injection attack is to trick a Web application into treating input as if it were code, and thereby taking control of an application. The most common injection attacks include SQL injection, XPATH, and HTML injection. Injection attacks are often the basis for other attacks such as cross-site scripting attacks (attacks which inject JavaScript code).
It is extremely difficult to test security into a project -- if not impossible. The key to fixing injection vulnerabilities is to not introduce them in the first place and/or to detect them in the build phase. Using static code analysis or similar automated tools will uncover a ton of these flaws. Still, no tool can replace a careful, experienced, methodical tester working her way through a Web application.
The first step in identifying injection flaws is to understand where user input is captured and used by the application. With injection attacks, it really doesn’t matter if the input is stored in a database or other file, or if it’s reflected back on the next page. The issue is to root out where unsanitized input is leveraged by the application. So it’s critical to understand the input and output of your application -- where is data brought into the application and where is it later output. This means that as a tester you will need to have a far better understanding of technical implementation of an application than if you were simply testing for conformance to requirements. By understanding the data flow, you can begin to probe how the application leverages data.
Another step in testing your application is to understand what technologies are leveraged.
For example, does your application run in an LDAP environment? Will LDAP injection testing be important? Is a SQL backend involved? Is your application architected such that XPATH or XQUERY are potential attack vectors? By understanding your application, you can develop an accurate sense of the scope of the project and what technologies and attacks you need to probe.
Your patience will be challenged by the next task -- documenting and executing tests.
Probing for SQL injection vulnerabilities in an application is fun and exciting the first few times – and in an unhealthy sense, discovering a valid defect is definitely rewarding. But these boundaries need to be probed control after control, page after page, POST parameter after POST parameter. It can become tedious. The good news is that this level of a “test everything” approach is generally a one-time process within legacy code. Once tested, always tested may not be an appropriate maxim, but it’s safe to say that a page which passed these tests last year and has not changed since is unlikely to have a new defect on it. There are a few commercial and open-source tools available to aid in your testing, but until a tester really knows an app, relying on an automated tool to probe every corner is insufficient.
A few additional notes to consider in your injection testing:
· Many applications are developed with client-side input validation. This is a good thing; it prevents the benevolent user from uploading bad data. Unfortunately, it sometimes prevents the inexperienced tester from fully testing an application.
· In order to get beyond client-side input validation, you will need to learn how to use a proxying tool. Using this tool, you will begin to learn what data is input into the application (there is much more “input” than just the controls on a web page). You’ll also be able to bypass client-side validation, so you can run malicious input tests.
· Even if potential injection vulnerability is addressed, it doesn’t mean it has been fixed. A common response to injection vulnerability is to “blacklist” various inputs (blacklisting means to explicitly deny any request for which the input matches a value in a list). Many hackers get around client- and server-side validation by encapsulating the text used in an attack.
The keys to succeeding at injection testing are
1) to be methodical,
2) to understand the technology underlying your application and
3) to use tools appropriately.
Why current application security measures fail and what you can do about it
By Kevin Beaver
It's like a broken record – we hear things like "integrate security into the application
lifecycle", "security must be built-in up front" and so on, over and over again. Evolved from an era that existed before application security was cool, we've been hearing people evangelize these statements for at least 10 years. But why do we still hear it? Perhaps the better question is: why aren't people integrating security with application lifecycle management? In this tip, I'll tell you common reasons security is not integrated; the risks businesses take by not taking security measures seriously and what you can do.
By John Overbaugh
One of the most challenging responsibilities of a tester is ensuring the security of a Web application. In this tip, I’ll cover a few steps testers can take to be more effective in testing
for OWASP’s top security vulnerability: injection.
According to the OWASP project:
Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. Attackers trick the interpreter into executing unintended commands via supplying specially crafted data. Injection flaws allow attackers to create, read, update, or delete any arbitrary data available to the application. In the worst case scenario, these flaws allow an attacker to completely compromise the application and the underlying systems, even bypassing deeply nested firewalled environments.
The goal of an injection attack is to trick a Web application into treating input as if it were code, and thereby taking control of an application. The most common injection attacks include SQL injection, XPATH, and HTML injection. Injection attacks are often the basis for other attacks such as cross-site scripting attacks (attacks which inject JavaScript code).
It is extremely difficult to test security into a project -- if not impossible. The key to fixing injection vulnerabilities is to not introduce them in the first place and/or to detect them in the build phase. Using static code analysis or similar automated tools will uncover a ton of these flaws. Still, no tool can replace a careful, experienced, methodical tester working her way through a Web application.
The first step in identifying injection flaws is to understand where user input is captured and used by the application. With injection attacks, it really doesn’t matter if the input is stored in a database or other file, or if it’s reflected back on the next page. The issue is to root out where unsanitized input is leveraged by the application. So it’s critical to understand the input and output of your application -- where is data brought into the application and where is it later output. This means that as a tester you will need to have a far better understanding of technical implementation of an application than if you were simply testing for conformance to requirements. By understanding the data flow, you can begin to probe how the application leverages data.
Another step in testing your application is to understand what technologies are leveraged.
For example, does your application run in an LDAP environment? Will LDAP injection testing be important? Is a SQL backend involved? Is your application architected such that XPATH or XQUERY are potential attack vectors? By understanding your application, you can develop an accurate sense of the scope of the project and what technologies and attacks you need to probe.
Your patience will be challenged by the next task -- documenting and executing tests.
Probing for SQL injection vulnerabilities in an application is fun and exciting the first few times – and in an unhealthy sense, discovering a valid defect is definitely rewarding. But these boundaries need to be probed control after control, page after page, POST parameter after POST parameter. It can become tedious. The good news is that this level of a “test everything” approach is generally a one-time process within legacy code. Once tested, always tested may not be an appropriate maxim, but it’s safe to say that a page which passed these tests last year and has not changed since is unlikely to have a new defect on it. There are a few commercial and open-source tools available to aid in your testing, but until a tester really knows an app, relying on an automated tool to probe every corner is insufficient.
A few additional notes to consider in your injection testing:
· Many applications are developed with client-side input validation. This is a good thing; it prevents the benevolent user from uploading bad data. Unfortunately, it sometimes prevents the inexperienced tester from fully testing an application.
· In order to get beyond client-side input validation, you will need to learn how to use a proxying tool. Using this tool, you will begin to learn what data is input into the application (there is much more “input” than just the controls on a web page). You’ll also be able to bypass client-side validation, so you can run malicious input tests.
· Even if potential injection vulnerability is addressed, it doesn’t mean it has been fixed. A common response to injection vulnerability is to “blacklist” various inputs (blacklisting means to explicitly deny any request for which the input matches a value in a list). Many hackers get around client- and server-side validation by encapsulating the text used in an attack.
The keys to succeeding at injection testing are
1) to be methodical,
2) to understand the technology underlying your application and
3) to use tools appropriately.
Why current application security measures fail and what you can do about it
By Kevin Beaver
It's like a broken record – we hear things like "integrate security into the application
lifecycle", "security must be built-in up front" and so on, over and over again. Evolved from an era that existed before application security was cool, we've been hearing people evangelize these statements for at least 10 years. But why do we still hear it? Perhaps the better question is: why aren't people integrating security with application lifecycle management? In this tip, I'll tell you common reasons security is not integrated; the risks businesses take by not taking security measures seriously and what you can do.
Why don't people integrate security into their application lifecycle?
Everyone has their theories as to why security is having so much trouble being included as a standard part of application lifecycle management. Working with developers, software testers, CIOs and system administrators in small, medium and large businesses across various industries, here's my take on the problem:
1. Key people writing and testing software are often excluded from ongoing security
and compliance meetings which, over time, can negate the very essence of what the
meetings are trying to accomplish in the first place.
2. Development and QA are often siloed entities that don't fall within the scope of
information security policies, compliance or business risk management.
3. Certain development and QA managers who are disconnected from application
security often assume that it requires no more than SSL, strong password policies
and role-based access controls.
4. Developers and QA staff are not encouraged – much less required – to take courses on application security. It's just "not in the budget."
5. The very people writing and testing the code are often in the dark on fully
understanding the realm of software security flaws, how the bad guys exploit these flaws, and (most importantly) which vulnerabilities are currently present in the
system from the bad guys' perspective.
6. Many people in development, QA and IT talk the security talk to management,
auditors, vendors and so on but there's no real accountability or follow-through.
7. There are too many people worried about calculating return on investment (ROI) and
hard risk numbers rather than building relationships and demonstrating tangible
evidence that security is improving software quality.
8. Oftentimes when software developers and testers are required to follow certain
security guidelines in the name of "compliance." There's substantial appeal in
checking off yet another line item requirement but application security for the sake
of compliance only serves to set everyone up for failure.
9. Business managers who don't understand application security or software testing
have zero empathy for what it takes to do either reasonably well.
Risks
All of these issues can lead to a myriad of business risks such as:
Contract and SLA violations, downstream liability and subsequent lawsuits resulting
from flawed applications delivered to customers and business partners
Security breaches resulting from vulnerabilities present in external and internal
business applications. Compliance violations and audit gaps resulting from the mishandling of personally-identifiable information (PII)
Source
Hack.lifepain.net
All of these issues can lead to a myriad of business risks such as:
Contract and SLA violations, downstream liability and subsequent lawsuits resulting
from flawed applications delivered to customers and business partners
Security breaches resulting from vulnerabilities present in external and internal
business applications. Compliance violations and audit gaps resulting from the mishandling of personally-identifiable information (PII)
Source
Hack.lifepain.net
0 comments:
Post a Comment