BWAPP - Revision history

SWeisser at 18:52, 18 December 2024

2024-12-18T18:52:22Z

@@ Line 314: / Line 314: @@
 </ul></div>
 <div style="border: 1px solid #eeb553; background-color: #f8e2bc; color: #c17c04; padding: 5px 10px; margin-bottom: 5px; text-align: justify">The highest security level specifies an array of allowed files, and the input must be one of them. If it is not, nothing is returned. The files in question are <i>"lang_en.php", "lang_fr.php", "lang_nl.php"</i>.</div>
 == References ==

NKirnbauer: gendering

2024-09-11T15:55:36Z

gendering

← Older revision		Revision as of 15:55, 11 September 2024
Line 26:		Line 26:
	== SQL injection ==		== SQL injection ==

	For a practical demonstration of bWAPP the SQL injection is elected. There are possible security lacks in a SQL database where an attacker can inject the database queries to obtain ~~his~~ desired result.</br>		For a practical demonstration of bWAPP the SQL injection is elected. There are possible security lacks in a SQL database where an attacker can inject the database queries to obtain their desired result.</br>
	*If the correct challenge (SQL injection (GET / SEARCH)) on the website has been selected, a new page opens with a search window and an empty table.</br>		*If the correct challenge (SQL injection (GET / SEARCH)) on the website has been selected, a new page opens with a search window and an empty table.</br>
	[[File:BWAPP SQLInjection.PNG\|500px\|center]]</br>		[[File:BWAPP SQLInjection.PNG\|500px\|center]]</br>
Line 190:		Line 190:
	[[File:StoredXSSAtt.png\|Example for stored XSS using a blog post]]		[[File:StoredXSSAtt.png\|Example for stored XSS using a blog post]]

	In the first part of the picture shows a regular blog of the BWAPP exercise "stored XSS (Blog)". Here a user can create a comment and after publishing any user who visits the page is able to see the published blog post. In this case a user has published a malicious blog post that is executed by every browser displaying this post. The post of this user consists of A regular commentary on the blog and a script. This script is responsible for creating variable to which an image element is assigned. This variable is than used to send the current browser cookie to the specified address. Since the the code is surrounded by the script tags it is never displayed to the user once published as seen below the code. The blog entry number 10 shows how this blog entry is displayed to every user visiting this page. As one can see there is now way one can tell that malicious code has been injected. In this case the blog and the attacker are in the same network, once someone views this entry the browser interprets and executes the script and sends the browser cookies of the current user to the attacker. The last part of the picture one sees the terminal of the attacker with netcat listening on port 9000 once the published entry of the attacker is viewed by someone this is what the attacker gets send. As one can see there is multiple information about the victim is displayed along this information is also the browser cookie which can have further used to the attacker. E.g. the attacker can impersonate the victim and let a web service believe ~~he is~~ the user he stole this information from. Most XSS attacks can be mitigated using proper input sanitization. E.g. a whitelist or blacklist can be created preventing the input of invalid input such as the script tag or greater/less than symbols which can be used for escaping tags and force script execution. Another option for mitigation is encoding where certain symbols considered enabling for script execution are encoded in a way they are safe to use as a user input.		In the first part of the picture shows a regular blog of the BWAPP exercise "stored XSS (Blog)". Here a user can create a comment and after publishing any user who visits the page is able to see the published blog post. In this case a user has published a malicious blog post that is executed by every browser displaying this post. The post of this user consists of A regular commentary on the blog and a script. This script is responsible for creating variable to which an image element is assigned. This variable is than used to send the current browser cookie to the specified address. Since the the code is surrounded by the script tags it is never displayed to the user once published as seen below the code. The blog entry number 10 shows how this blog entry is displayed to every user visiting this page. As one can see there is now way one can tell that malicious code has been injected. In this case the blog and the attacker are in the same network, once someone views this entry the browser interprets and executes the script and sends the browser cookies of the current user to the attacker. The last part of the picture one sees the terminal of the attacker with netcat listening on port 9000 once the published entry of the attacker is viewed by someone this is what the attacker gets send. As one can see there is multiple information about the victim is displayed along this information is also the browser cookie which can have further used to the attacker. E.g. the attacker can impersonate the victim and let a web service believe they are the user they stole this information from. Most XSS attacks can be mitigated using proper input sanitization. E.g. a whitelist or blacklist can be created preventing the input of invalid input such as the script tag or greater/less than symbols which can be used for escaping tags and force script execution. Another option for mitigation is encoding where certain symbols considered enabling for script execution are encoded in a way they are safe to use as a user input.

	== Heartbleed ==		== Heartbleed ==

MBoysen: /* Cross-Site Scripting (XSS) */

2023-01-05T16:25:54Z

Cross-Site Scripting (XSS)

← Older revision		Revision as of 16:25, 5 January 2023
Line 184:		Line 184:
	return addslashes($data);		return addslashes($data);
	}		}

			<b>XSS Stored (Blog) </b><br>
			The picture below displays a stored XSS attack using a blog post.

			[[File:StoredXSSAtt.png\|Example for stored XSS using a blog post]]

			In the first part of the picture shows a regular blog of the BWAPP exercise "stored XSS (Blog)". Here a user can create a comment and after publishing any user who visits the page is able to see the published blog post. In this case a user has published a malicious blog post that is executed by every browser displaying this post. The post of this user consists of A regular commentary on the blog and a script. This script is responsible for creating variable to which an image element is assigned. This variable is than used to send the current browser cookie to the specified address. Since the the code is surrounded by the script tags it is never displayed to the user once published as seen below the code. The blog entry number 10 shows how this blog entry is displayed to every user visiting this page. As one can see there is now way one can tell that malicious code has been injected. In this case the blog and the attacker are in the same network, once someone views this entry the browser interprets and executes the script and sends the browser cookies of the current user to the attacker. The last part of the picture one sees the terminal of the attacker with netcat listening on port 9000 once the published entry of the attacker is viewed by someone this is what the attacker gets send. As one can see there is multiple information about the victim is displayed along this information is also the browser cookie which can have further used to the attacker. E.g. the attacker can impersonate the victim and let a web service believe he is the user he stole this information from. Most XSS attacks can be mitigated using proper input sanitization. E.g. a whitelist or blacklist can be created preventing the input of invalid input such as the script tag or greater/less than symbols which can be used for escaping tags and force script execution. Another option for mitigation is encoding where certain symbols considered enabling for script execution are encoded in a way they are safe to use as a user input.

	== Heartbleed ==		== Heartbleed ==

VHorvathova: /* Remote & Local File Inclusion (RFI/LFI) */

2022-01-26T22:00:55Z