Gain insights into web app vulnerabilities and attack methods, delve into penetration testing with Kali Linux, and explore tools for enhancing information security using Python, web tech, and network management.

webpen.tar.gz

shodan_api

Wireshark

chrome

Burp

frog

proxychains

encoder

setoolkitChrome

chromeShark

juiceshop

BurpChrome

This course is intended for people interested in information security—particularly in the penetration testing of various websites—to identify the security flaws present in the majority of newly developed websites and how to fix them. 

You will learn web penetration testing techniques using the Kali Linux operating system. You will be introduced to Python programming, web server technology, network management, open source intelligence, cross-site scripting, SQL injection, authentication and authorization in systems, cross-site request forgery, social engineering attacks, and concepts in information security management. 

Your knowledge of the various web application vulnerabilities and attack methods will be enhanced after taking this course. You will get hands-on experience with many tools used in online penetration testing in cyber security.

Web Application Penetration Testing

## Overview

XSS attacks can be truly annoying, especially since most are due to shoddy coding practices. With the examples discussed in the previous lesson, we can easily infer how much damage someone with malicious intent can cause. Fortunately, most XSS-related vulnerabilities can be addressed by just writing good code and simple manual checks. Tools like [OWASP ZAP](https://www.zaproxy.org/) can also work quite nicely (since it has a good success rate with Juice Shop).

## Mitigation methods

Let's look at a few golden rules that need to be kept in mind when coding web applications.

### Modern frameworks

If we're using modern frameworks, such as React, Angular, or Vue, to build our web applications, then we're mostly safe from XSS attacks. These frameworks ensure secure coding practices due to the way they work. Keep in mind though, we can intentionally make our web application insecure with special configurations, so be wary of that. Also, there are still some avenues where frameworks can't provide security, so proper knowledge is required to handle such cases.

### Avoid untrusted input

Users should only be allowed to input data where they're supposed to. They should also only be able to make changes to pages they're authorized and authenticated to do so. The reflected and DOM XSS examples show that anyone could be affected by such attacks. Using unique identifiers could prevent such wide-net attacks.

The Mozilla Firefox browser and applications such as Burp Suite allow users to repeat requests with custom parameters. This might prove dangerous if we don't check for this custom input since since it deviates from the intended behavior of the web application.

### Filter user input

User input should always go through validation. Rigorous testing is required to ensure that users cannot input content they're not supposed to. For example, the username field of a login form really shouldn't be able to accept HTML tags as input.

Additionally, we should encode output to prevent user-provided data from being automatically executed by a browser.

### Use a Content Security Policy (CSP)

A **Content Security Policy (CSP)** determines what websites the browser can consider trustworthy sources of executable scripts  when the scripts are being queried by a website. For example, let's assume we want to visit niceshoes.com. This website gets content and some business logic from third-party sites, such as store.niceshoes.com and google-ads.net. An adversary realizes that there is a form on the website that doesn't sanitize input, and they enter malicious code that tries to steal users' cookies and send them to their own evil web server. However, since the CSP dictates that scripts with origins other than store.niceshoes.com and google-ads.net should be ignored, the attack will fail.

# Overview

XSS attacks can be truly annoying, especially since most are due to shoddy coding practices. With the examples discussed in the previous lesson, we can easily infer how much damage someone with malicious intent can cause. Fortunately, most XSS-related vulnerabilities can be addressed by just writing good code and simple manual checks. Tools like [OWASP ZAP](https://www.zaproxy.org/) can also work quite nicely (since it has a good success rate with Juice Shop).

# Mitigation methods

Let's look at a few golden rules that need to be kept in mind when coding web applications.

## Modern frameworks

If we're using modern frameworks, such as React, Angular, or Vue, to build our web applications, then we're mostly safe from XSS attacks. These frameworks ensure secure coding practices due to the way they work. Keep in mind though, we can intentionally make our web application insecure with special configurations, so be wary of that. Also, there are still some avenues where frameworks can't provide security, so proper knowledge is required to handle such cases.

## Avoid untrusted input

Users should only be allowed to input data where they're supposed to. They should also only be able to make changes to pages they're authorized and authenticated to do so. The reflected and DOM XSS examples show that anyone could be affected by such attacks. Using unique identifiers could prevent such wide-net attacks.

The Mozilla Firefox browser and applications such as Burp Suite allow users to repeat requests with custom parameters. This might prove dangerous if we don't check for this custom input since since it deviates from the intended behavior of the web application.

## Filter user input

User input should always go through validation. Rigorous testing is required to ensure that users cannot input content they're not supposed to. For example, the username field of a login form really shouldn't be able to accept HTML tags as input.

Additionally, we should encode output to prevent user-provided data from being automatically executed by a browser.

## Use a Content Security Policy (CSP)

A **Content Security Policy (CSP)** determines what websites the browser can consider trustworthy sources of executable scripts  when the scripts are being queried by a website. For example, let's assume we want to visit niceshoes.com. This website gets content and some business logic from third-party sites, such as store.niceshoes.com and google-ads.net. An adversary realizes that there is a form on the website that doesn't sanitize input, and they enter malicious code that tries to steal users' cookies and send them to their own evil web server. However, since the CSP dictates that scripts with origins other than store.niceshoes.com and google-ads.net should be ignored, the attack will fail.

Learn how to mitigate XSS attacks by writing secure code and setting up proper configurations.

Introduction to the Course

Introduction to Linux

Introduction to Python

Web and Server Technology

Network Management and Analysis

Open-Source Intelligence

Cross-Site Scripting

SQL Injection

Authentication and Authorization

Cross-Site Request Forgery

Social Engineering Attacks

Broader Security Concepts

Wrapping Up

Mitigation of XSS

Overview

Mitigation methods