OWASP Amass Project

The OWASP Amass Project performs network mapping of attack surfaces and external asset discovery using open source information gathering and active reconnaissance techniques.

This tool maintains a strong focus on DNS, HTTP and SSL/TLS data discovering and scrapping. To do this, it has its own techniques and provides several integrations with different API services like (spoiler alert!) the SecurityTrails API.

Amass enum can be executed under the context of a passive or an active configuration mode. The passive mode is much quicker, but Amass will not validate DNS information, for example by resolving the subdomains.

Links:

• OWASP Amass
• Quick Tutorial & Example Usage
• A solid information gathering tool 
  

 

The 2021 OWASP Top 10 Have Evolved

The OWASP Top 10 is an awareness document that highlights the top 10 most critical web application security risks. The risks are in a ranked order based on frequency, severity, and magnitude for impact.

OWASP has maintained this list since 2003, and every few years, they update the list based on advancements in both application development and application security. 

The last OWASP Top 10 came out in 2017, and in the intervening 4 years, we've seen a fundamental shift in application security that includes greater emphasis on securing web applications during the ever-evolving development process.

So, what's changed?

OWASP released their new OWASP Top 10 for 2021. Check out the changes below:

OWASP Top 10: 2017 Vs 2021

 

Examples of the new changes include:

• The introduction of insecure design 
• Broadened focus of injections
• Vulnerable and outdated components replace “using components with known vulnerabilities" 

 

Links:

• https://www.rapid7.com/blog/post/2021/09/30/the-2021-owasp-top-10-have-evolved-heres-what-you-should-know/
  

OWASP 2010

Since 2003, OWASP (Open Web Application Security Project) has been making an effort to inform web decision makers of the 10 most critical web application security flaws are through their Top 10 Project (link to: http://www.owasp.org/index.php/OWASP_Top_10_Project). 2010 marks the third update to this list after a final draft to the original released in 2004 and an update to the list in 2007.

OWASP is “an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted.” Their work is derived from a collaboration of security professionals who serve as volunteers to bring information to the community in an open and unbiased manner. While the organization is not affiliated with any technology or security companies, they do support the use of commercial security products.

The Top 10
The Top 10 project is described by OWASP as:

The OWASP Top 10 provides a powerful awareness document for web application security. The OWASP Top 10 represents a broad consensus about what the most critical web application security flaws are.

One of the most noticeable changes to the Top 10 list is the focus being shifted from a list of the top 10 vulnerabilities to the top 10 risks. The reason for the shift is quite practical, “Actually, it moved from prevalence (which is one factor of likelihood) to risk, which takes into likelihood and prevalence to estimate risk. Organizations care about risk, not just likelihood, and the Top 10 was always about risk (really), but we weren’t as clear as we should be, so this update works to make that much more clear.” Dave Wichers, Project Leader for the Top 10 List.

Additionally, two risks were dropped from this update: Malicious File Execution due to tighter PHP security lowering the prevalence of this problem, and Information Leakage and Improper Error Handling because of a minimal zed impact of disclosing stack trace and error message information.

Injection

• Examples of injection flaws are SQL, LDAP, HTTP header injection (cookies, requests), and OS command injections
• Attacks occur when untrusted data, such as a query, command or argument, is sent to an interpreter
• Vulnerable applications can be tricked into executing unintended commands or allowing the attacker to access, and modify, data

Cross Site Scripting

• There are three types of XSS attacks: stored, reflected, and Dom based
• XSS attacks occur when an application allows data that is not validated or escaped properly to be sent to a web browser
• Malicious scripts are executed in the victim’s browser allowing the attacker to hijack the user’s session, steal cookies, deface web sites, redirect users to malicious web sites, and remote browser control

Broken Authentication and Session Management

• Users are impersonated due to leaks or flaws in the authentication process
• Attacks occur when a session ID is visible to others, timeouts are not properly set, SSL/TLS is not used, or any other flaw in the authentication scheme is detected
• Flaws used against one account may be replicated against an account with higher privileges

Insecure Direct Object References

• Attack occurs when an authorized user can change a parameter value that refers to a system object that they are not authorized for
• Almost any reference that can be reached by URL to include: references to files, paths, database keys, reflection by class name (e.g. JDBC connector class)
• Remote referencing includes: Web Services, CORBA, RMI, RPC

Cross Site Request Forgery (CSRF)

• Attacker creates malicious code to generate a forged request that the attacker tricks the victim into submitting
• Forged requests can be hidden in image tags, XSS attacks and a number of other techniques
• CSRF attacks can complete any transactions that the victim is permitted to perform such as access data, transfer funds or make purchases

Security Misconfiguration

• New to the 2010 update
• Attacker exploits unsecured pages, default accounts, unpatched flaws or any other vulnerability that could have be addressed by proper configuration
• These attacks can result in a complete system compromise

Failure to Restrict URL Access

• This attack takes place when an authorized user can simply change a URL to access a privileged page
• Attackers generally look for administrative functions to employ this attack on
• Links can be obtained from: hidden fields, client-side code, robots.txt, configuration files, static XML files, directory access

Unvalidated Redirects and Forwards

• New to the 2010 update
• Unvalidated parameter allows an attacker to choose a destination page where they wish to send a victim to trick them into disclosing private information
• Victims trust these links because the link is to a valid site

Insecure Cryptographic Storage

• The most common reason for this attack is that data that should be encrypted is stored in cleartext
• Can result from the poor use of encryption algorithms such as using home grown algorithms, insecure use of strong algorithms or the continued use of proven weak algorithms
• The use of weak or unsalted hashes to protect passwords is another common flaw that leads to this risk

Insufficient Transport Layer Protection

• Most commonly, this attack occurs when a site does not use SSL/TLS for pages that require authentication where an attacker can monitor network traffic to steal an authenticated user’s session cookie
• Poorly configured SSL certificates can lull a user into accepting warnings for legitimate sites only to be tricked into accepting a phishing site’s certificate
• Attacks can lead to account theft, phishing attacks and admin accounts being compromised

HTTP Parameter Pollution

>>>> New type of attack on web applications: Parameter Pollution

At the recent OWASP conference, the Italian security experts Luca Carettoni and Stefano Di Paola demonstrated a new way of manipulating web applications and tricking security systems: HTTP Parameter Pollution (HPP).

This form of attack essentially involves submitting the parameters in GET and POST requests in unusual form or order, or with unusual delimiters. A request like:

GET /foo?par1=val1&par2=val2 HTTP/1.1

will be processed in the normal way, while

GET /foo?par1=val1&par1=val2 HTTP/1.1

with two occurrences of par1 can result in various different server-side variable interpretations, depending on the web server's or application's parsing routine. According to Carettoni and Di Paola, this can cause the application to behave in an unwanted and highly unpredictable way and result in security issues.

Web application firewalls (WAFs) and server security extensions are also vulnerable to HPP attacks. While Apache's ModSecurity module recognises an SQL-injection attack like:

/index.aspx?page=select 1,2,3 from table where id=1

it fails to detect

/index.aspx?page=select 1&page=2,3 from table where id=1

say the security experts. HPP can reportedly also be exploited for launching Cross-Site-Scripting attacks (XSS) on web browsers. The XSS filter of Internet Explorer 8 is apparently among the components vulnerable to this kind of attack.

Carettoni and Di Paola recommend stricter filtering and URL encoding to counteract HPP. They also recommend using strict regular expressions in URL rewriting.

Building Security in Maturity Model

Software security again.

In 2006, software security found itself embodied in three major methodologies: Microsoft SDL, Cigital Touchpoints, and OWASP CLASP. Of course there are more. BSIMM selects 9 (out of 35 software security initiatives) and creates a Software Security Framework (SSF).

The BSIMM is about helping us to determine where our organization stands with respect to software security initiatives and what steps can be taken to make it more effective.

For a concise description of the BSIMM, read the informIT article Software [In]security: The Building Security In Maturity Model (BSIMM), Confessions of a Software Security Alchemist.

You can download the document from here.