CategoryWeb App Security Testing

Everything relating to web app security testing and penetration testing lives in this category.

Why is Web Application Penetration Testing Important?

If you have successfully run your dynamic and static scans and implemented a secure development life cycle throughout your web applications development; you might feel pretty confident your web app is secure. But how sure are you? You may have performed automated web application vulnerability assessments and everything looks good, but to be really sure you should hire a professional web application penetration tester who will manually assess your application for vulnerabilities.

Many areas of web application security testing cannot be successfully automated. For example, a vulnerability assessment tool would be able to successfully tell you that a web application has bad HTTPS configuration, or that a web server version is out of date and in some cases software can identify vulnerabilities such as XSS and SQLi when they are obviously vulnerable.

What is web application penetration testing?

Web application penetration testing, also widely regarded as website or web application security testing, is an in-depth assessment of a web application. A skilled and certified consultant will manually assess your web application for security issues and vulnerabilities, often identifying issues that automated software would simply miss. The manual element of the assessment also allows for a tester to combine multiple lower level security issues to leverage higher level vulnerabilities or even compromise the web application.

Parts of a web application have to be assessed manually, for example session management. It‘s not realistic to expect an automated tool to fully assess an applications session management for all areas covered in the OWASP testing framework. The same logic would apply to access control testing, where a penetration tester manually assess that a lower level user cannot access parts of the application or functionality intended for privileged users. An example would using an API function as a low level user and resetting an administrators password simply by modifying the request.

Severity levels can also be manually assessed with a web application penetration test, a consultant can see the full picture and assign a risk accordingly instead of issuing a boiler plate severity that is not based on the circumstance, which automated software would issue.

If you are depending on automate alone to ensure your applications security, it’s simply not sufficient. While manual web application penetration testing does not ensure or guarantee that an application is free of security issues or vulnerabilities it will typically identify far more issues than just performing an automated vulnerability assessment.

How often does MPT need to be performed on an application?
So, now that you seem to have a basic understanding of what MPT entails, the next thing that would need to be figured out is how often an organisation should perform it.

Depending on your risk management deployment and program, it would be recommended that you schedule an annual web application penetration test for your web applications. This is general good practice, web applications are often modified or frameworks and software used by them become vulnerable. And lastly because your application might need to be meet compliance requirements and specific regulatory standards such as PCI DSS may dictate more frequent testing.

A good use case for a web app security assessment is to use it as a final check, after internal developers have completed remediating flaws that would be found through dynamic and static scans. An external 3rd party penetration testing company can assess the application from an outside prospective with no prior knowledge, often providing unique insight and identifying issues your team did not even know exist or could be exploited in such a way.

TIP – When Sourcing Web App Security Assessment Quotes

A common problem when sourcing quotes for web app pen testing are clients and confusing the service with a vulnerability assessment. Due to this kind of confusion arising, pricing for assessment will often appear to be all over the place. Ensure your web application assessment is conducted manually and is closely aligned with the OWAP testing methodology.

How to prepare for a web application penetration test?

  • Leverage dynamic, static, and software composition analysis technologies in order to find known vulnerabilities. This approach would help to yield higher fidelity results.
  • The external 3rd party team should work with you in order to document your specific concerns and needs, discuss any scoping questions, and record and test logistics information.
  • Lastly, a member of the team should also confirm the testing dates and rules of engagement prior to testing.

We hope this has given you some insight as to why it’s important to conduct security and penetration testing against web applications.

OWASP Top 10 for 2017 Updated

OWASP stands for Open Web Application Security Project and the Top 10 list lists the most critical web application security issues. In April OWASP publicly released the release candidate for the OWASP Top 10 2017 list, with the final version scheduled for final release in June or July 2017 after a public commenting period which ends June 30th

What is OWASP?

OWASP (Open Web Application Security Project) is a non-profit community that understands these risks and every couple of years they release a list show casing the top 10 vulnerabilities to web application security.

OWASP Top 10 2017 Summary:

Name Desctiption
A1 – Injection Injection flaws, such as SQL, OS, XXE, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
A2 – Broken Authentication and Session Management Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities (temporarily or permanently).
A3 – Cross-Site Scripting (XSS) XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user supplied data using a browser API that can create JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
A4 – Broken Access Control Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.
A5 -Security Misconfiguration Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, platform, etc. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.
A6 – Sensitive Data Exposure Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.
A7 – Insufficient Attack Protection *NEW* The majority of applications and APIs lack the basic ability to detect, prevent, and respond to both manual and automated attacks. Attack protection goes far beyond basic input validation and involves automatically detecting, logging, responding, and even blocking exploit attempts. Application owners also need to be able to deploy patches quickly to protect against attacks.
A8 – Cross-Site Request Forgery (CSRF) A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. Such an attack allows the attacker to force a victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
A9 – Using Components with Known Vulnerabilities Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.
A10 – Underprotected APIs *NEW* Modern applications often involve rich client applications and APIs, such as JavaScript in the browser and mobile apps, that connect to an API of some kind (SOAP/XML, REST/JSON, RPC, GWT, etc.). These APIs are often unprotected and contain numerous vulnerabilities.

How Did It Differ from the 2013 List?

For the most part, the list remained the same. However, two new categories were added that should now ensure are assessed by your internal or external web application security testing company, consultants or teams. Two categories from the previous list were merged into one, a new category was added and an old category was dropped from the list all together.  Many speculate that these new additions to the list show just how digital security is evolving, but others point out just how similar the two lists are and believe that the problem stems from the developers and their practices being stagnant. The two new categories are Insufficient Attack Protection and Unprotected API’s.


What Are these New Categories and What do they Imply?

The newest vulnerability, Insufficient Attack Protection, proposes that many cyberattacks make a lot nose and generate a lot of abnormal traffic through your network and inputs while executing their infiltration. However, vulnerability scanners will pick this up and start to generate a ton of unusual requests. So, to combat this risk OWASP recommended a WAF or Web Application Firewall or an IPS (intrusion prevention system).

The second risk has everything to do with unprotected APIs or Application Program Interfaces. OWASP has noticed major vulnerabilities based on the data structures and complex protocols of this feature how it lacks a User Interface. This kind of vulnerability in a banking app could give hackers the opportunity to modify account numbers of money being sent out because there is no authentication process. Many speculate that these new risks reflect the shift towards high-speed software development.


How will this Impact OWASP Top Ten List in the Future?

It is still too early to say since the list is still being worked on. Security experts, users, and developers are submitting comments about the new list proposal the final version is expected to be released next summer but many agree that the inclusion of APIs was a smart decision and is a solid reflection of the times and the increased risks and vulnerabilities in the development of API platforms.  Such inclusion in the OWASP top 10 2017 list would greatly raise awareness of API security risks and help could potentially inspire new safeguards and implementation of newer techniques to help keep information used with an API safer.


What Else Has Changed?

Back in the 2007 version of the list, the Broken Access Control category was split into two. It has been that way up until now, in the 2017 version the category was merged back into one. Also, the category Unvalidated Redirects and Forwards has been dropped all together. Not that it still isn’t a common risk, however, it doesn’t measure up to the threat level of new risks that OWASP is including in the 2017 list.


Living Up to the Name

OWASP is a major influence on application security and its ever-evolving status. OWASP designed their list to help developers avoid many of the common bugs that people tend to run into. OWASP illustrates a standard of security and provides a precedent for application security programs. They have set the tone for security program priorities and with the many security holes found in APIs, people will soon shift their priorities to designing measures that counteract API attacks and that will help combat some of the many vulnerabilities this system. This change in the OWASP 2017 list is a clear indication of times to come.

Drop us a comment below and let us know what you think of the new OWASP Top 10 2017!

© 2017 Clerkendweller

Theme by Anders NorénUp ↑