Richie's Notes - richnadeau/Secure-Web-Application-CTF-Nadeau-Notter GitHub Wiki

This includes Cross-site Scripting, SQL Injection, and External Control of File Name or Path. Any application is vulnerable to this attack if the end user's supplied data is not filtered or validated by the application, dynamic queries are used directly in the interpreter, hostile data is being used to extract sensitive records via object-relational mapping search parameters, and the SQL or command contains the structure and data to make these dynamic queries, commands or stored procedures.

To prevent or reduce the chances of getting breached by injection, using safe API is a good option as it avoids the interpreter altogether. Using positive server-side input validation can be helpful as well. For residual dynamic queries use the escape syntax for whatever interpreter is being used so that they cannot be successfully used. Lastly, using LIMIT and other SQL controls within queries to prevent a mass disclosure and extraction of record via SQL injection is a good idea as well.

Scenarios

An application uses untrusted data in the construction of the following vulnerable SQL call:

String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";

An application’s blind trust in frameworks may result in queries that are still vulnerable:

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

The attacker modifies the 'id' parameter in their browser to the following:

http://example.com/app/accountView?id=' or '1'='1

This will by pass any permissions as the last part (' or '1'='1`) is true and will be ran in the SQL database and retrieve the attacker the wanted sensitive data.

This is a new category for 2021 which I think a lot of people do not really think about personally. This category is less technical and more about the design or architecture of an application or feature. Do not be confused with insecure implementation as that is what most of the other categories fall under. A secure design can still have implementation defects which make that secure design vulnerable, but because it has a secure design it may be harder for a less technical person to be able to exploit it. On the other hand, an insecure design cannot be fixed even by perfect implementation because the needed security controls were never even created to defend against some attacks allowing it to be exploited easier.

To prevent insecure designs, establishing a secure development life cycle to evaluate security controls, limiting resource consumption by users and services, and using a threat model for critical authentication, access control, and business logic.

Scenarios

A password reset has a user answer simple security questions relating to the user in order to recover their password. The problem with this is that more than one person can know the answers to these security questions and someone else may be able to successfully answer them and recover their password and get into their account. Sending a reset code to their email or phone number would be a more secure way of doing this.

A sporting event allows you to book up to 10 seats without needing to pay a deposit. This makes it easier for a malicious user to book up all the tickets without paying any money causing a loss of revenue for the owners running the sporting event. Having people pay in advance in order to reserve those tickets would be a better way to go about selling the tickets.

A online electronic retail store does not have protection against bots on their website. When a new and limited product drops on their website, they can be immediately bought out by bots ran by scalpers who will then proceed to resell the product for a higher amount than its retail price due to their limited availability (think GPU/PS5/Xbox shortages and scalpers). Having anti-bot design such as CAPTCHA would limit the amount of bots that would be able to buy out the limited products.

A SSRF flaw occurs when a web application is fetching a remote resource without validating the user-supplied URL. With this, an attacker can create a crafter request to an unexpected destination even if it protected by a firewall, VPN, or other ACL.

To prevent this at the network layer, try segmenting your network so if someone was to get remote resource access it will reduce the impact of it via privilege escalation. Enforcing deny by defaults on firewall policies is a good idea too so nothing but essential traffic is able to go through them. At the application layer, make sure that your application validates all client input data, enforce URL schema, port, and destination with an allow list, never send raw responses to clients, and disabling http redirects.

Scenarios

An attacker can run a port scan across all your internal servers if given access to the network. They can then find which services and ports may be vulnerable to SSRF. If the network architecture is unsegmented, the attacker can figure out where to try and jump to from the vulnerable server they may have been able to exploit

Once connected, attackers would be able to access local files to gain sensitive information such as file:///etc/passwd</span> and http://localhost:28017/.

An attacker can compromise internal services by conducting further attacks such as remote code execution and denial of service once connected to a server.

A03 Injection - OWASP Top 10:2021. https://owasp.org/Top10/A03_2021-Injection/. Accessed 21 Jan. 2022.

A07 Identification and Authentication Failures - OWASP Top 10:2021. https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/. Accessed 21 Jan. 2022.

A10 Server Side Request Forgery (SSRF) - OWASP Top 10:2021. https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/. Accessed 21 Jan. 2022.