Elvis Wiki - User contributions [en]

WebScanPro

2024-03-31T17:58:25Z

RHaidl: fixed typo "Next.js" -> "Nest.js"

== Summary ==
WebScanPro is a web application designed for the analysis of HTTP security headers.
Developed with a user-friendly interface and robust scanning capabilities, WebScanPro helps developers to strengthen the security of their web applications.
In addition WebScanPro also scans the TLS/SSL Version and provides feedback if it the certificate version should be updated or is up to date.

== HTTP Headers ==
=== Content-Security-Policy ===
The HTTP Content-Security-Policy response header allows website administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (Cross-site scripting).

=== Strict-Transport-Security (HSTS) ===
The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) lets a website tell browsers that it should only be accessed using HTTPS, instead of using HTTP. Most websites automatically redirect to https but this header should still be used e.g. to prevent SSL Stripping attacks (When users visit a website, they first connect with the HTTP version before getting rerouted to the HTTPS version. In SSL stripping attacks, hackers jump in this window to act as a man in the middle and prevent users from ever connecting with the HTTPS version of the site.)

=== X-XSS-Protection===
Browser stops loading the page if it detects reflected XSS
Use a Content Security Policy (CSP) that disables the use of inline JavaScript.

Do not set this header or explicitly turn it off.

=== X-Content-Type-Options ===
Blocks mime type sniffing and should be set as followed:
<code>X-Content-Type-Options: nosniff</code>

=== X-Frame-Options ===
The X-Frame-Options HTTP response header can be used to indicate whether a browser should be allowed to render a page in a <code><frame></code>, <code><iframe></code>, <code><embed></code>, or <code><object></code>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites. Should be set to <code>DENY</code> or <code>SAMEORIGIN</code>

=== Referrer-Policy ===
Referrer policy has been supported by browsers since 2014. Today, the default behavior in modern browsers is to no longer send all referrer information (origin, path, and query string) to the same site but to only send the origin to other sites. However, since not all users may be using the latest browsers and websites can (but should not!) have sensitive data in the query it is suggested forcing this behavior by sending this header on all responses.

=== X-Webkit-CSP & X-Content-Security-Policy ===
Deprecated. Should only be used to implement CSP for very old browsers (<2013)

=== Permissions-Policy ===
Permissions-Policy allows you to control which origins can use which browser features, both in the top-level page and in embedded frames. For every feature controlled by Feature Policy, the feature is only enabled in the current document or frame if its origin matches the allowed list of origins. This means that you can configure your site to never allow the camera or microphone to be activated.

This prevents that an injection, for example an XSS, enables the camera, the microphone, or other browser feature.
<code>Permissions-Policy: geolocation=(), camera=(), microphone=()</code>
This example is disabling geolocation, camera and microphne on all domains.

=== X-Powered-By-Policy ===
The X-Powered-By header describes the technologies used by the webserver. This information exposes the server to attackers. Using the information in this header, attackers can find vulnerabilities easier.

== SSL/TLS Versions ==

=== TLS Version 1.3 ===
TLS 1.3 is the latest and most secure version of the TLS protocol. It offers improved security, faster handshake, and enhanced privacy features.

It is strongly recommended to use TLS 1.3 for the highest level of security.

=== TLS Version 1.2 ===
TLS 1.2 is a widely adopted and secure version of the TLS protocol. It provides strong encryption and security features. While not the latest version, it is still considered secure and is widely supported.

But an update to Version 1.3 is recommended.

=== TLS Version 1.1 ===
TLS 1.1 is outdated and has known vulnerabilities. It is generally not recommended to use TLS 1.1 due to security concerns.

Upgrading to a newer version, preferably TLS 1.3, is highly recommended.

=== TLS Version 1.0 ===
TLS 1.0 is outdated and has significant security vulnerabilities.

Upgrading to a newer version, preferably TLS 1.3, is highly recommended.

=== SSL Version 3 ===
SSLv3 is obsolete and has serious security flaws, including the POODLE vulnerability.

Upgrading to a newer version, preferably TLS 1.3, is highly recommended.

=== SSL Version 2 ===
SSLv2 is extremely outdated and insecure, with numerous vulnerabilities. Its use is strongly discouraged, and modern systems no longer support it.

Upgrading to a newer version, preferably TLS 1.3, is highly recommended.

== Requirements ==

* [https://nodejs.org Node.js]

== Architecture ==
'''Frontend:'''
* [https://angular.io/ Angular]
* [https://www.chartjs.org/ Chart.js]

'''Backend:'''
* [https://nestjs.com/ Nest.js]
* [https://axios-http.com/ axios]

== Description ==

=== Step 1 ===

Install [https://nodejs.org Node.js]

=== Step 2 ===

Clone [https://git.fh-campuswien.ac.at/c1810475113/WebScanPro.git WebScanPro respository]

=== Step 3 ===

Run '''npm install'''

=== Step 4 ===

Run '''npm start'''

=== Step 5 ===

Open '''localhost:3000'''

<small>'''Hint:''' if this port is already in use, you can change <syntaxhighlight lang="cpp">app.listen(3000)</syntaxhighlight> in <code>nest-js-server/main.ts</code> to another port which is not in use.</small>

=== Step 6 ===

Start scanning your web application and check the results.
Have fun!

[[Category:Documentation]]

WebScanPro

2024-01-24T18:01:29Z

RHaidl: /* Summary */

== Summary ==
WebScanPro is a web application designed for the analysis of HTTP security headers.
Developed with a user-friendly interface and robust scanning capabilities, WebScanPro helps developers to strengthen the security of their web applications.
In addition WebScanPro also scans the TLS/SSL Version and provides feedback if it the certificate version should be updated or is up to date.

== HTTP Headers ==
=== Content-Security-Policy ===
The HTTP Content-Security-Policy response header allows website administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (Cross-site scripting).

=== Strict-Transport-Security (HSTS) ===
The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) lets a website tell browsers that it should only be accessed using HTTPS, instead of using HTTP. Most websites automatically redirect to https but this header should still be used e.g. to prevent SSL Stripping attacks (When users visit a website, they first connect with the HTTP version before getting rerouted to the HTTPS version. In SSL stripping attacks, hackers jump in this window to act as a man in the middle and prevent users from ever connecting with the HTTPS version of the site.)

=== X-XSS-Protection===
Browser stops loading the page if it detects reflected XSS
Use a Content Security Policy (CSP) that disables the use of inline JavaScript.

Do not set this header or explicitly turn it off.

=== X-Content-Type-Options ===
Blocks mime type sniffing and should be set as followed:
<code>X-Content-Type-Options: nosniff</code>

=== X-Frame-Options ===
The X-Frame-Options HTTP response header can be used to indicate whether a browser should be allowed to render a page in a <code><frame></code>, <code><iframe></code>, <code><embed></code>, or <code><object></code>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites. Should be set to <code>DENY</code> or <code>SAMEORIGIN</code>

=== Referrer-Policy ===
Referrer policy has been supported by browsers since 2014. Today, the default behavior in modern browsers is to no longer send all referrer information (origin, path, and query string) to the same site but to only send the origin to other sites. However, since not all users may be using the latest browsers and websites can (but should not!) have sensitive data in the query it is suggested forcing this behavior by sending this header on all responses.

=== X-Webkit-CSP & X-Content-Security-Policy ===
Deprecated. Should only be used to implement CSP for very old browsers (<2013)

=== Permissions-Policy ===
Permissions-Policy allows you to control which origins can use which browser features, both in the top-level page and in embedded frames. For every feature controlled by Feature Policy, the feature is only enabled in the current document or frame if its origin matches the allowed list of origins. This means that you can configure your site to never allow the camera or microphone to be activated.

This prevents that an injection, for example an XSS, enables the camera, the microphone, or other browser feature.
<code>Permissions-Policy: geolocation=(), camera=(), microphone=()</code>
This example is disabling geolocation, camera and microphne on all domains.

=== X-Powered-By-Policy ===
The X-Powered-By header describes the technologies used by the webserver. This information exposes the server to attackers. Using the information in this header, attackers can find vulnerabilities easier.

== SSL/TLS Versions ==

=== TLS Version 1.3 ===
TLS 1.3 is the latest and most secure version of the TLS protocol. It offers improved security, faster handshake, and enhanced privacy features.

It is strongly recommended to use TLS 1.3 for the highest level of security.

=== TLS Version 1.2 ===
TLS 1.2 is a widely adopted and secure version of the TLS protocol. It provides strong encryption and security features. While not the latest version, it is still considered secure and is widely supported.

But an update to Version 1.3 is recommended.

=== TLS Version 1.1 ===
TLS 1.1 is outdated and has known vulnerabilities. It is generally not recommended to use TLS 1.1 due to security concerns.

Upgrading to a newer version, preferably TLS 1.3, is highly recommended.

=== TLS Version 1.0 ===
TLS 1.0 is outdated and has significant security vulnerabilities.

Upgrading to a newer version, preferably TLS 1.3, is highly recommended.

=== SSL Version 3 ===
SSLv3 is obsolete and has serious security flaws, including the POODLE vulnerability.

Upgrading to a newer version, preferably TLS 1.3, is highly recommended.

=== SSL Version 2 ===
SSLv2 is extremely outdated and insecure, with numerous vulnerabilities. Its use is strongly discouraged, and modern systems no longer support it.

Upgrading to a newer version, preferably TLS 1.3, is highly recommended.

== Requirements ==

* [https://nodejs.org Node.js]

== Architecture ==
'''Frontend:'''
* [https://angular.io/ Angular]
* [https://www.chartjs.org/ Chart.js]

'''Backend:'''
* [https://nestjs.com/ Next.js]
* [https://axios-http.com/ axios]

== Description ==

=== Step 1 ===

Install [https://nodejs.org Node.js]

=== Step 2 ===

Clone [https://git.fh-campuswien.ac.at/c1810475113/WebScanPro.git WebScanPro respository]

=== Step 3 ===

Run '''npm install'''

=== Step 4 ===

Run '''npm start'''

=== Step 5 ===

Open '''localhost:3000'''

<small>'''Hint:''' if this port is already in use, you can change <syntaxhighlight lang="cpp">app.listen(3000)</syntaxhighlight> in <code>nest-js-server/main.ts</code> to another port which is not in use.</small>

=== Step 6 ===

Start scanning your web application and check the results.
Have fun!

[[Category:Documentation]]

WebScanPro

2024-01-24T17:59:37Z

RHaidl: added HTTP headers and SSL/TLS Version

== Summary ==
WebScanPro is a web application designed for the analysis of HTTP security headers.
Developed with a user-friendly interface and robust scanning capabilities, WebScanPro helps developers to strengthen the security of their web applications.

== HTTP Headers ==
=== Content-Security-Policy ===
The HTTP Content-Security-Policy response header allows website administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (Cross-site scripting).

=== Strict-Transport-Security (HSTS) ===
The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) lets a website tell browsers that it should only be accessed using HTTPS, instead of using HTTP. Most websites automatically redirect to https but this header should still be used e.g. to prevent SSL Stripping attacks (When users visit a website, they first connect with the HTTP version before getting rerouted to the HTTPS version. In SSL stripping attacks, hackers jump in this window to act as a man in the middle and prevent users from ever connecting with the HTTPS version of the site.)

=== X-XSS-Protection===
Browser stops loading the page if it detects reflected XSS
Use a Content Security Policy (CSP) that disables the use of inline JavaScript.

Do not set this header or explicitly turn it off.

=== X-Content-Type-Options ===
Blocks mime type sniffing and should be set as followed:
<code>X-Content-Type-Options: nosniff</code>

=== X-Frame-Options ===
The X-Frame-Options HTTP response header can be used to indicate whether a browser should be allowed to render a page in a <code><frame></code>, <code><iframe></code>, <code><embed></code>, or <code><object></code>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites. Should be set to <code>DENY</code> or <code>SAMEORIGIN</code>

=== Referrer-Policy ===
Referrer policy has been supported by browsers since 2014. Today, the default behavior in modern browsers is to no longer send all referrer information (origin, path, and query string) to the same site but to only send the origin to other sites. However, since not all users may be using the latest browsers and websites can (but should not!) have sensitive data in the query it is suggested forcing this behavior by sending this header on all responses.

=== X-Webkit-CSP & X-Content-Security-Policy ===
Deprecated. Should only be used to implement CSP for very old browsers (<2013)

=== Permissions-Policy ===
Permissions-Policy allows you to control which origins can use which browser features, both in the top-level page and in embedded frames. For every feature controlled by Feature Policy, the feature is only enabled in the current document or frame if its origin matches the allowed list of origins. This means that you can configure your site to never allow the camera or microphone to be activated.

This prevents that an injection, for example an XSS, enables the camera, the microphone, or other browser feature.
<code>Permissions-Policy: geolocation=(), camera=(), microphone=()</code>
This example is disabling geolocation, camera and microphne on all domains.

=== X-Powered-By-Policy ===
The X-Powered-By header describes the technologies used by the webserver. This information exposes the server to attackers. Using the information in this header, attackers can find vulnerabilities easier.

== SSL/TLS Versions ==

=== TLS Version 1.3 ===
TLS 1.3 is the latest and most secure version of the TLS protocol. It offers improved security, faster handshake, and enhanced privacy features.

It is strongly recommended to use TLS 1.3 for the highest level of security.

=== TLS Version 1.2 ===
TLS 1.2 is a widely adopted and secure version of the TLS protocol. It provides strong encryption and security features. While not the latest version, it is still considered secure and is widely supported.

But an update to Version 1.3 is recommended.

=== TLS Version 1.1 ===
TLS 1.1 is outdated and has known vulnerabilities. It is generally not recommended to use TLS 1.1 due to security concerns.

Upgrading to a newer version, preferably TLS 1.3, is highly recommended.

=== TLS Version 1.0 ===
TLS 1.0 is outdated and has significant security vulnerabilities.

Upgrading to a newer version, preferably TLS 1.3, is highly recommended.

=== SSL Version 3 ===
SSLv3 is obsolete and has serious security flaws, including the POODLE vulnerability.

Upgrading to a newer version, preferably TLS 1.3, is highly recommended.

=== SSL Version 2 ===
SSLv2 is extremely outdated and insecure, with numerous vulnerabilities. Its use is strongly discouraged, and modern systems no longer support it.

Upgrading to a newer version, preferably TLS 1.3, is highly recommended.

== Requirements ==

* [https://nodejs.org Node.js]

== Architecture ==
'''Frontend:'''
* [https://angular.io/ Angular]
* [https://www.chartjs.org/ Chart.js]

'''Backend:'''
* [https://nestjs.com/ Next.js]
* [https://axios-http.com/ axios]

== Description ==

=== Step 1 ===

Install [https://nodejs.org Node.js]

=== Step 2 ===

Clone [https://git.fh-campuswien.ac.at/c1810475113/WebScanPro.git WebScanPro respository]

=== Step 3 ===

Run '''npm install'''

=== Step 4 ===

Run '''npm start'''

=== Step 5 ===

Open '''localhost:3000'''

<small>'''Hint:''' if this port is already in use, you can change <syntaxhighlight lang="cpp">app.listen(3000)</syntaxhighlight> in <code>nest-js-server/main.ts</code> to another port which is not in use.</small>

=== Step 6 ===

Start scanning your web application and check the results.
Have fun!

[[Category:Documentation]]

WebScanPro

2024-01-23T19:52:04Z

RHaidl: fixed structure of Architecture

WebScanPro

2024-01-23T19:51:21Z

RHaidl: fixed typo

WebScanPro

2024-01-23T19:50:26Z

RHaidl: WebScanPro is a web application which scans and analyzes HTTP security headers.

Practical stored XSS Example using Burp Suite

2023-01-08T11:24:31Z

RHaidl:

== Summary ==

This practical guide shows how to execute a stored XSS exploit using burp suite.

== Requirements ==

* Burp Suite
* Visual Studio
* GIT Project (https://github.com/Robert-Haidl/XSS_stored)

In order to complete these steps, you must have followed the readme [https://github.com/Robert-Haidl/XSS_stored/blob/main/README.md] before.

== Description ==

===Setup===
* Download Burp Suite (https://portswigger.net/burp/communitydownload)
* Clone GIT Project and run it locally using VisualStudios integrated IIS Express server.
* Check if you can add blog entries

=== Step 1 ===

Open Burp Suite, navigate to Proxy -> Intercept and make sure to turn '''Intercept on'''.

[[File:stored_xss_step1.png|600px|turn on intercept]]

=== Step 2 ===

Click on "'''Open Browser'''" in order to open the integrated Burp Suite browser.
Once the browser started (it takes a while), open the '''add-entry.html''' file in it.

=== Step 3 ===
As the interceptor is turned on, all requests from the client to the server are intercepted.
All requests need to be forwarded, til the website has loaded completely. (Click on '''Forward''')
[[File:stored_xss_step2.png|600px|intercepted request]]

=== Step 4 ===
Once the website has loaded, fill out the form with data and submit it.
Now you can see, that the client sends a POST request to the backend with the content of the form in JSON format.

[[File:stored_xss_step3.png|600px|intercepted POST request]]

=== Step 5 ===
As the transmitted data in the POST request is '''not validated on server side''', you can change a parameter of the JSON to arbitrary JavaScript code.

In this tutorial we change the ''''description'''' parameter to the following JavaScript code

<code><script>alert('XSS Code Injection')</script></code>

and then forward the request.

[[File:stored_xss_step4.png|600px|modified POST request]]

=== Step 6 ===
Once you submitted the form and forwarded the request to the server you need to either turn off the Interceptor because you have already sent the malicious code to the server (where it has been saved to the database) or forward all requests. After that you will be automatically redirected to the '''show-entry.html''' file where the '''malicious code is loaded from the server (DB) and executed on the client browser'''.

[[File:stored_xss_step5.png|600px|javascript code is executed]]

== References ==

* https://portswigger.net/burp/documentation/desktop/penetration-testing

[[Category:Documentation]]

Practical stored XSS Example using Burp Suite

2023-01-08T11:22:29Z

RHaidl:

== Summary ==

This practical guide shows how to execute a stored XSS exploit using burp suite.

== Requirements ==

* Burp Suite
* Visual Studio
* GIT Project (https://github.com/Robert-Haidl/XSS_stored)

In order to complete these steps, you must have followed the readme [https://github.com/Robert-Haidl/XSS_stored/blob/main/README.md] before.

== Description ==

===Setup===
* Download Burp Suite (https://portswigger.net/burp/communitydownload)
* Clone GIT Project and run it locally using VisualStudios integrated IIS Express server.
* Check if you can add blog entries

=== Step 1 ===

Open Burp Suite, navigate to Proxy -> Intercept and make sure to turn '''Intercept on'''.

[[File:stored_xss_step1.png|600px|turn on intercept]]

=== Step 2 ===

Click on "'''Open Browser'''" in order to open the integrated Burp Suite browser.
Once the browser started (it takes a while), open the '''add-entry.html''' file in it.

=== Step 3 ===
As the interceptor is turned on, all requests from the client to the server are intercepted.
All requests need to be forwarded, til the website loaded completely. (Click on '''Forward''')
[[File:stored_xss_step2.png|600px|intercepted request]]

=== Step 4 ===
Once the website has loaded, fill out the form with data and submit it.
Now you can see, that the client sends a POST request to the backend with the content of the form in JSON.

[[File:stored_xss_step3.png|600px|intercepted POST request]]

=== Step 5 ===
Change the sent JSON data of the POST request. (use a parameter, which is displayed in the frontend e.g. 'description')
As the transmitted data in the POST request is not validated on server side, you can change a parameter of the JSON to arbitrary JavaScript code.

In this tutorial we change the 'description' parameter to the following JavaScript code

<code><script>alert('XSS Code Injection')</script></code>

and then forward the request.

[[File:stored_xss_step4.png|600px|modified POST request]]

=== Step 6 ===
Once you submitted the form and forwarded the request to the server you need to either turn off the Interceptor because you have already sent the malicious code to the server (where it has been saved to the database) or forward all requests. After that you will be automatically redirected to the '''show-entry.html''' file where the malicious is loaded from the server (DB) and executed on the client browser.

[[File:stored_xss_step5.png|600px|javascript code is executed]]

== References ==

* https://portswigger.net/burp/documentation/desktop/penetration-testing

[[Category:Documentation]]

Practical stored XSS Example using Burp Suite

2023-01-08T11:21:44Z

RHaidl:

== Summary ==

This practical guide shows how to execute a stored XSS exploit using burp suite.

== Requirements ==

* Burp Suite
* Visual Studio
* GIT Project (https://github.com/Robert-Haidl/XSS_stored)

In order to complete these steps, you must have followed the readme [https://github.com/Robert-Haidl/XSS_stored/blob/main/README.md] before.

== Description ==

===Setup===
* Download Burp Suite (https://portswigger.net/burp/communitydownload)
* Clone GIT Project and run it locally using VisualStudios integrated IIS Express server.
* Check if you can add blog entries

=== Step 1 ===

Open Burp Suite, navigate to Proxy -> Intercept and make sure to turn '''Intercept on'''.

[[File:stored_xss_step1.png|600px|turn on intercept]]

=== Step 2 ===

Click on "'''Open Browser'''" in order to open the integrated Burp Suite browser.
Once the browser started (it takes a while), open the '''add-entry.html''' file.

=== Step 3 ===
As the interceptor is turned on, all requests from the client to the server are intercepted.
All requests need to be forwarded, til the website loaded completely. (Click on '''Forward''')
[[File:stored_xss_step2.png|600px|intercepted request]]

=== Step 4 ===
Once the website has loaded, fill out the form with data and submit it.
Now you can see, that the client sends a POST request to the backend with the content of the form in JSON.

[[File:stored_xss_step3.png|600px|intercepted POST request]]

=== Step 5 ===
Change the sent JSON data of the POST request. (use a parameter, which is displayed in the frontend e.g. 'description')
As the transmitted data in the POST request is not validated on server side, you can change a parameter of the JSON to arbitrary JavaScript code.

In this tutorial we change the 'description' parameter to the following JavaScript code

<code><script>alert('XSS Code Injection')</script></code>

and then forward the request.

[[File:stored_xss_step4.png|600px|modified POST request]]

=== Step 6 ===
Once you submitted the form and forwarded the request to the server you need to either turn off the Interceptor because you have already sent the malicious code to the server (where it has been saved to the database) or forward all requests. After that you will be automatically redirected to the '''show-entry.html''' file where the malicious is loaded from the server (DB) and executed on the client browser.

[[File:stored_xss_step5.png|600px|javascript code is executed]]

== References ==

* https://portswigger.net/burp/documentation/desktop/penetration-testing

[[Category:Documentation]]

Practical stored XSS Example using Burp Suite

2023-01-08T11:20:54Z

RHaidl:

== Summary ==

This practical guide shows how to execute a stored XSS exploit using burp suite.

== Requirements ==

* Burp Suite
* Visual Studio
* GIT Project (https://github.com/Robert-Haidl/XSS_stored)

In order to complete these steps, you must have followed the readme [https://github.com/Robert-Haidl/XSS_stored/blob/main/README.md] before.

== Description ==

===Setup===
* Download Burp Suite (https://portswigger.net/burp/communitydownload)
* Clone GIT Project and run it locally using VisualStudios integrated IIS Express server.
* Check if you can add blog entries

=== Step 1 ===

Open Burp Suite, navigate to Proxy -> Intercept and make sure to turn '''Intercept on'''.

[[File:stored_xss_step1.png|600px|turn on intercept]]

=== Step 2 ===

Click on "Open Browser" in order to open the integrated Burp Suite browser.
Once the browser started (it takes a while), open the '''add-entry.html''' file.

=== Step 3 ===
As the interceptor is turned on, all requests from the client to the server are intercepted.
All requests need to be forwarded, til the website loaded completely. (Click on '''Forward''')
[[File:stored_xss_step2.png|600px|intercepted request]]

=== Step 4 ===
Once the website has loaded, fill out the form with data and submit it.
Now you can see, that the client sends a POST request to the backend with the content of the form in JSON.

[[File:stored_xss_step3.png|600px|intercepted POST request]]

=== Step 5 ===
Change the sent JSON data of the POST request. (use a parameter, which is displayed in the frontend e.g. 'description')
As the transmitted data in the POST request is not validated on server side, you can change a parameter of the JSON to arbitrary JavaScript code.

In this tutorial we change the 'description' parameter to the following JavaScript code

<code><script>alert('XSS Code Injection')</script></code>

and then forward the request.

[[File:stored_xss_step4.png|600px|modified POST request]]

=== Step 6 ===
Once you submitted the form and forwarded the request to the server you need to either turn off the Interceptor because you have already sent the malicious code to the server (where it has been saved to the database) or forward all requests. After that you will be automatically redirected to the '''show-entry.html''' file where the malicious is loaded from the server (DB) and executed on the client browser.

[[File:stored_xss_step5.png|600px|javascript code is executed]]

== References ==

* https://portswigger.net/burp/documentation/desktop/penetration-testing

[[Category:Documentation]]

File:Stored xss step5.png

2023-01-08T11:12:05Z

RHaidl:

File:Stored xss step4.png

2023-01-08T10:57:46Z

RHaidl:

File:Stored xss step3.png

2023-01-08T10:54:59Z

RHaidl:

File:Stored xss step2.png

2023-01-08T10:47:53Z

RHaidl:

Practical stored XSS Example using Burp Suite

2023-01-08T10:02:22Z

RHaidl:

== Summary ==

This practical guide shows how to generate a stored XSS exploit using burp suite.

== Requirements ==

* Burp Suite
* Visual Studio
* GIT Project (https://github.com/Robert-Haidl/XSS_stored)

In order to complete these steps, you must have followed the readme [https://github.com/Robert-Haidl/XSS_stored/blob/main/README.md] before.

== Description ==

===Setup===
* Download and run Burp Suite (https://portswigger.net/burp/communitydownload)
* Clone GIT Project and run it locally using VisualStudios integrated IIS Express server.
* Check if you can add blog entries

=== Step 1 ===

Open Burp Suite, navigate to Proxy -> Intercept and make sure to turn Intercept on.

[[File:stored_xss_step1.png|600px|thumb|left|turn on intercept]]

== References ==

* https://portswigger.net/burp/documentation/desktop/penetration-testing

[[Category:Documentation]]

Practical stored XSS Example using Burp Suite

2023-01-08T10:01:42Z

RHaidl:

== Summary ==

This practical guide shows how to generate a stored XSS exploit using burp suite.

== Requirements ==

* Burp Suite
* Visual Studio
* GIT Project (https://github.com/Robert-Haidl/XSS_stored)

In order to complete these steps, you must have followed the readme ([[https://github.com/Robert-Haidl/XSS_stored/blob/main/README.md]]) before.

== Description ==

===Setup===
* Download and run Burp Suite (https://portswigger.net/burp/communitydownload)
* Clone GIT Project and run it locally using VisualStudios integrated IIS Express server.
* Check if you can add blog entries

=== Step 1 ===

Open Burp Suite, navigate to Proxy -> Intercept and make sure to turn Intercept on.

[[File:stored_xss_step1.png|600px|thumb|left|turn on intercept]]

== References ==

* https://portswigger.net/burp/documentation/desktop/penetration-testing

[[Category:Documentation]]

Practical stored XSS Example using Burp Suite

2023-01-08T10:01:25Z

RHaidl: Created page with "== Summary == This practical guide shows how to generate a stored XSS exploit using burp suite. == Requirements == * Burp Suite * Visual Studio * GIT Project (https://github.com/Robert-Haidl/XSS_stored) In order to complete these steps, you must have followed the readme (https://github.com/Robert-Haidl/XSS_stored/blob/main/README.md) before. == Description == ===Setup=== * Download and run Burp Suite (https://portswigger.net/burp/communitydownload) * Clone GIT..."

== Summary ==

This practical guide shows how to generate a stored XSS exploit using burp suite.

== Requirements ==

* Burp Suite
* Visual Studio
* GIT Project (https://github.com/Robert-Haidl/XSS_stored)

In order to complete these steps, you must have followed the readme ([[https://github.com/Robert-Haidl/XSS_stored/blob/main/README.md]]) before.

== Description ==

===Setup===
* Download and run Burp Suite (https://portswigger.net/burp/communitydownload)
* Clone GIT Project and run it locally using VisualStudios integrated IIS Express server.
* Check if you can add blog entries

=== Step 1 ===

Open Burp Suite, navigate to Proxy -> Intercept and make sure to turn Intercept on.

[[File:stored_xss_step1.png|600px|thumb|right|turn on intercept]]

== References ==

* https://portswigger.net/burp/documentation/desktop/penetration-testing

[[Category:Documentation]]

File:Stored xss step1.png

2023-01-08T09:57:00Z

RHaidl:

Cross-Site Scripting (XSS)

2023-01-07T12:52:39Z

RHaidl: added more prevention methods and listed them in a more structured way

[[Category:Basic]]
== Cross-Site-Scripting (XSS) ==

Cross-Site Scripting is a class of web application vulnerabilities, which is still one of the most common security vulnerabilities in web applications and can be used to compromise the confidentiality, integrity, and availability of the application. In general, XSS vulnerabilities allow an attacker to execute script code in the web browser of the victim and can be used to gain data from users, like cookies or private information. The different types are listed below. It is also possible to trigger actions on websites, redirect to other sites or hide advertisements. A short game with which some options can be seen easily: [https://xss-game.appspot.com/ XSS game]

== Types ==
There are two ways to classify XSS attacks. Up until 2012 the types DOM-based (Type 0), stored/persistent (Type I) and reflected/non-persistent (Type II) were used. As these three types can overlap the research community started to use the terms Server XSS and Client XSS from 2012 on.
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]

=== Stored (Type I) ===
With Stored XSS, also referred to as persistent XSS, the application or API saves uncleaned user input on the server, such as in a database, comment field, visitor log, etc., which then is displayed at a later point in time by another user or administrator, that requested the stored information.

=== Reflected (Type II) ===
Reflected XSS is a non-persistent attack and is used to steal session cookies from a user. With Reflected XSS, the application or API includes unchecked and unmasked input from the user as part of the HTML output. If the attack was successful, the attacker could execute arbitrary HTML and a scripting language such as Javascript in the victim's browser. Typically, a user will have to click on a malicious link to do this. The attacker tries to bring this harmful link to the victim, via advertising, e-mail etc.

=== DOM Based (Type 0) ===
DOM-based Cross-Site Scripting (XSS) is a type of XSS attack that occurs when malicious code is injected directly into the Document Object Model (DOM) of the web application. DOM-based XSS attacks can occur when user-supplied data is used to generate client-side JavaScript code without proper input validation. The malicious code is then sent to a user's browser, where it is executed. DOM-based XSS attacks can be used to gain access to sensitive information, perform malicious activities, and even hijack the user’s browser.

== Prevention==

The prevention of these vulnerabilities are the task of the programmer. The programmer should be encouraged to use secure programming measures, like Context-sensitive server-side output encoding, to ensure that it is not possible to inject malicious scripts into the site through incorrect or unchecked entries.

* Input validation: The most effective way to prevent cross-site scripting attacks is to perform rigorous input validation. This means validating any user input before it is accepted and processed by the server.
* Output encoding: Output encoding is another effective way to prevent cross-site scripting. This technique involves encoding all output data (using HTML entities) so that it is properly displayed in the user’s browser.
*Content Security Policy: Content Security Policy (CSP) is a security measure that can be used to prevent cross-site scripting attacks. It is a set of rules that define what type of content a website can load.
*Use of tokens: Tokens are random strings of characters that are used to identify a user. This can help to prevent cross-site scripting attacks by ensuring that only authorized users can access the website.
*Disabling script execution: Disabling script execution on the server can also help to prevent cross-site scripting attacks. This can be done by disabling the use of certain scripting languages such as JavaScript or VBScript. But as JavaScript is commonly used, this approach is rarely used by programmers.

== References ==

* https://owasp.org/www-community/attacks/xss/
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)

Cross-Site Request Forgery (CSRF)

2023-01-07T10:02:46Z

RHaidl: added Same-Origin Policy

[[Category:Basic]]
== Cross-Site-Request Forgery (CSRF) ==

Cross-Site Request Forgery, also known as CSRF or XSRF, is an attack where a malicious website, email message, web application, or blog causes an unwanted web browser action on a trusted site where a user is currently authenticated. The consequences of a CSRF attack depend on the extent to which the vulnerable application is hit. In the simplest case, attackers use CSRF attacks to cause a target system to perform available and malicious functions through the target's browser without the target user's knowledge. This function is usually not known to the victim until after it occurs.

A CSRF vulnerability allows an attacker to force an authenticated, logged-in user to perform an important action without the user's consent or knowledge. This way leaves no trace of the attacker from the web application's point of view. The reason for this is, the fake request contains all the victim's information and comes from the same IP address as a real request from the victim. As a consequence, any application that allows a user to send or update data is a potential target for an attacker.

The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. This may be a complication for attackers, but many websites allow users to click something like "Stay logged in," which makes the attacker's job easier.

== File Inclusion ==
===Local File Inclusion (LFI)===
Local File Inclusion (LFI) is a type of Cross-Site Request Forgery (CSRF) attack in which an attacker injects malicious code into a vulnerable web application to gain access to sensitive information stored in the web server's local file system. The attacker is able to execute arbitrary code on the server by exploiting the application's security vulnerabilities. The malicious code is then used to download and modify web application files, steal privileged information, or even execute malicious code on the server.
===Remote File Inclusion (RFI)===
Remote File Inclusion (RFI) is a type of attack where an attacker tricks a web server into including a malicious file from a remote server. The malicious file may contain code to steal data, modify data, or launch other attacks on the vulnerable web server. It can also allow the attacker to gain access to sensitive information, such as user credentials and other sensitive data.

== Prevention ==

To detect this vulnerability, one checks that each link and form is protected with an unpredictable "secret" token. Alternatively, one can have the user reconfirm the request, e.g., by re-authenticating or entering CAPTCHA. Here, one can focus on links and forms that actually trigger a state-changing function, as these are the most important targets for CSRF. Multi-step transactions should also be examined, as they can be equally vulnerable. An attacker can easily trigger a sequence of fake requests by using multiple tags or even JavaScript.

To prevent CSRF, each input page should contain a token. The token should be unpredictable, secret and unique for each session, or better for each form, and
checked by the server. CSRF tokens should be generated on the server-side. Generally, per-request tokens are more secure than per-session tokens as the time range for an attacker to exploit the stolen tokens is minimal.

* The preferred method to embed the token is a hidden input field. This way the token value is transferred in the body of the request and not in the URL, which otherwise facilitates spying.

* Such a token can also be written directly into the URL or passed as a URL parameter. However, by doing that we fix one security flaw by creating a new one. This approach carries the risk that the URL falls into the hands of the attacker and thus the secret token is compromised.

* Active reconfirmation from the user, in the form of re-authentication, CAPTCHA input, etc. can also protect against CSRF.

Generally, it is recommended to use built-in or existing CSRF implementations for CSRF Protection. OWASP also advises to research if the framework used in your project has an option to achieve CSRF Protection, since many Frameworks have built-in implementations for these types of attacks.

===Same-Origin Policy===
Another possibility for preventing Cross-Site Request Forgery is the Same-Origin Policy, which is a security measure implemented by web browsers to restrict malicious activity from websites by preventing cross-site requests. This policy means that a web browser will only allow a web page to access resources from the same origin (domain, protocol, and port) as the page itself. By restricting access to resources from the same origin, the Same-Origin Policy helps to ensure that only the intended website can access the resources and prevent malicious attempts to hijack the user's session.

== References ==

* https://owasp.org/www-community/attacks/csrf
* https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
* https://owasp.org/www-community/Anti_CRSF_Tokens_ASP-NET
* https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

Cross-Site Request Forgery (CSRF)

2023-01-07T09:53:20Z

RHaidl: added File Inclusion section

[[Category:Basic]]
== Cross-Site-Request Forgery (CSRF) ==

Cross-Site Request Forgery, also known as CSRF or XSRF, is an attack where a malicious website, email message, web application, or blog causes an unwanted web browser action on a trusted site where a user is currently authenticated. The consequences of a CSRF attack depend on the extent to which the vulnerable application is hit. In the simplest case, attackers use CSRF attacks to cause a target system to perform available and malicious functions through the target's browser without the target user's knowledge. This function is usually not known to the victim until after it occurs.

A CSRF vulnerability allows an attacker to force an authenticated, logged-in user to perform an important action without the user's consent or knowledge. This way leaves no trace of the attacker from the web application's point of view. The reason for this is, the fake request contains all the victim's information and comes from the same IP address as a real request from the victim. As a consequence, any application that allows a user to send or update data is a potential target for an attacker.

The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. This may be a complication for attackers, but many websites allow users to click something like "Stay logged in," which makes the attacker's job easier.

== File Inclusion ==
===Local File Inclusion (LFI)===
Local File Inclusion (LFI) is a type of Cross-Site Request Forgery (CSRF) attack in which an attacker injects malicious code into a vulnerable web application to gain access to sensitive information stored in the web server's local file system. The attacker is able to execute arbitrary code on the server by exploiting the application's security vulnerabilities. The malicious code is then used to download and modify web application files, steal privileged information, or even execute malicious code on the server.
===Remote File Inclusion (RFI)===
Remote File Inclusion (RFI) is a type of attack where an attacker tricks a web server into including a malicious file from a remote server. The malicious file may contain code to steal data, modify data, or launch other attacks on the vulnerable web server. It can also allow the attacker to gain access to sensitive information, such as user credentials and other sensitive data.

== Prevention ==

To detect this vulnerability, one checks that each link and form is protected with an unpredictable "secret" token. Alternatively, one can have the user reconfirm the request, e.g., by re-authenticating or entering CAPTCHA. Here, one can focus on links and forms that actually trigger a state-changing function, as these are the most important targets for CSRF. Multi-step transactions should also be examined, as they can be equally vulnerable. An attacker can easily trigger a sequence of fake requests by using multiple tags or even JavaScript.

To prevent CSRF, each input page should contain a token. The token should be unpredictable, secret and unique for each session, or better for each form, and
checked by the server. CSRF tokens should be generated on the server-side. Generally, per-request tokens are more secure than per-session tokens as the time range for an attacker to exploit the stolen tokens is minimal.

* The preferred method to embed the token is a hidden input field. This way the token value is transferred in the body of the request and not in the URL, which otherwise facilitates spying.

* Such a token can also be written directly into the URL or passed as a URL parameter. However, by doing that we fix one security flaw by creating a new one. This approach carries the risk that the URL falls into the hands of the attacker and thus the secret token is compromised.

* Active reconfirmation from the user, in the form of re-authentication, CAPTCHA input, etc. can also protect against CSRF.

Generally, it is recommended to use built-in or existing CSRF implementations for CSRF Protection. OWASP also advises to research if the framework used in your project has an option to achieve CSRF Protection, since many Frameworks have built-in implementations for these types of attacks.

== References ==

* https://owasp.org/www-community/attacks/csrf
* https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
* https://owasp.org/www-community/Anti_CRSF_Tokens_ASP-NET