make a good business better
Print Divider Print Divider Branding

​LBMC conducts “grey box” (meaning no access to source code) web application security assessments on the identified applications to determine if someone might be able to compromise the security of the application itself or the data therein. The objective of the web application security assessment is to evaluate the security of the identified applications by searching for vulnerabilities that could be exploited by an attacker. This assessment will determine the security posture of the application and will provide recommendations for improving its overall security.

LBMC evaluates the security of the identified web application by “interacting” with it from the Internet. The scope of our testing will include manual and automated intelligent fuzzing, testing access controls, testing application logic, testing authentication, and testing session management. This manual and automated testing will be performed using commercial and/or open-source web application tools coupled with our testing team’s extensive experience in hunting and exploiting application security weaknesses across all industries. This testing will evaluate each accessible area of the application for common web application security flaws, including but not limited to those outlined in the Open Web Application Security Project’s (OWASP) “Top 10”, as described below.

Injection

We test for Injection flaws that may occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code. They are often found in SQL, LDAP, Xpath, or NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc. The most widely recognized injection flaw is referred to as SQL Injection (SQLi).

Broken Authentication and Session Management

We will test for flaws that involve developers frequently building custom authentication and session management schemes, as it is known that building these correctly is difficult. As a result, these custom schemes frequently have flaws in areas such as logout, password management, timeouts, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique.

Cross-Site Scripting (XSS)

Unfortunately, XSS is the most prevalent web application security flaws. XSS flaws occur when an application includes user supplied data in a page sent to the browser without properly validating or escaping that content. There are two different types of XSS flaws: 1) Stored and 2) Reflected, and each of these can occur on the a) Server or b) on the Client. Detection of most Server XSS flaws is fairly easy via dynamic testing. However, Client XSS is very difficult to identify.

Insecure Direct References

We will test for applications that frequently use the actual name or key of an object when generating web pages. Applications don’t always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Attackers can easily manipulate parameter values to detect such flaws.

Security Misconfigurations

We recognize that security misconfigurations can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code. Our testing is useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc.

Sensitive Data Exposure

We understand that one of the most common flaws is simply not encrypting sensitive data. When cryptography is employed, weak key generation and management, and weak algorithm usage is common, particularly weak password hashing techniques. Browser weaknesses are very common and easy to detect, but hard to exploit on a large scale. External attackers have difficulty detecting server side flaws due to limited access and they are also usually hard to exploit.

Missing Function Level Access Control

It is important to realize that applications do not always protect application functions properly. Sometimes, function level protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and this can be forgotten. Detecting such flaws my often be simple. However, the hardest part is identifying which pages (URLs) or functions exist to attack.

Cross Site Request Forgery

CSRF s one of the more complex vulnerabilities that takes advantage of the fact that most web apps allow attackers to predict all the details of a particular action. Because web browsers send credentials like session cookies automatically, attackers can create malicious web pages which generate forged requests that are indistinguishable from legitimate ones. Detection of CSRF flaws can be fairly easy to identify via dynamic web application testing.

Using Components with Known Vulnerabilities

Virtually every application has these issues because most development teams don’t focus on ensuring their components/libraries are up to date. In many cases, the developers don’t even know all the components they are using, never mind their versions. Component dependencies make things even worse.

Unvalidated Redirects and Forwards

Applications frequently redirect users to other pages, or use internal forwards in a similar manner. Sometimes the target page is specified in an unvalidated parameter, allowing attackers to choose the destination page. Detecting unchecked redirects can be relatively simple. However, one should look for redirects where you can set the full URL. Unchecked forwards are harder, because they target internal pages.

As many application vulnerabilities stem from input supplied to the application, our testing will spend extensive focus on areas that process user-supplied data. In addition to the well documented OWASP testing objectives, LBMC also focuses on various application logic testing that requires extensive manual testing for situations involving account creation, password resets, login parameters, privilege escalation, etc. When testing production applications, LBMC will not execute potentially destructive exploits.

In an effort to increase code coverage and to appropriately model particular threats common to many applications, we recommend our attack simulations be conducted from various roles and access levels to include one or more of the following:

1) No access, simulating anyone on the Internet (unauthenticated)

2) Basic or limited end user access (authenticated) 

3) Power User (to the web application

4) Administrator Level (to the web application)

Once the application security testing is complete, LBMC assists in understanding the security implications of the discovered vulnerabilities through examples and proof of concepts where appropriate. Using this process, LBMC will be able to provide a clear picture of any security weaknesses that exist in the applications, as well as the likelihood of successful exploitation.

The resultant product of the web application security assessment will be a comprehensive report that includes executive summary information, supporting data, and detailed remediation steps to resolve discovered security vulnerabilities of varying severities. If validated vulnerabilities that have the capability impact on the confidentiality, integrity, or availability of the application or relevant data are discovered, LBMC will immediately provide the needed information to resolve the issue prior to providing the initial report.

Get More Information on Web Application Security Assessments