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

Technological advancements have led to the development of rather sophisticated attacks. With each passing day, adversaries are mitigated, but that doesn't stop them; they come up with new ways of circumventing security. One such act of cleverness, at least when it was first discovered, is the **cross-site request forgery (CSRF)** attack.

# What is a CSRF attack?

A CSRF attack targets a user with an account on a vulnerable web application. The goal is to trick users to perform actions that they don't intend to perform, and the approach aims to bypass the same-origin policy. This might sound similar to some other forms of attacks so let's take a deeper look.

For a CSRF attack to be crafted, the web application should rely on cookie-based session handling. For authentication and authorization, the web application should only be looking at the cookie of the user. Any extra validation steps will greatly increase the difficulty of a CSRF attack taking place.

Let's assume a web application, example.com, is highly vulnerable to CSRF. A user is currently logged in. The web application has a simple mechanism for changing a user's own password—a basic HTTP request that automatically includes the user's session ID (from the cookie) and the only user-input parameter is the new password. An adversary can make a simple web page, for example, that contains a form with a hidden input field that submits a new password for the user chosen by the adversary. If the target user clicks on the web page, because the cookie is automatically picked up by the user's browser (since they're logged in), the user's password will be changed to one picked by the adversary. Keep in mind that a simple check of asking the user for their current password before making the password change request will mitigate this attack.

Now imagine this happening with a banking website. The consequences could be catastrophic. This is one of the main reasons why they log us out after just a few minutes of inactivity. A further multi-factor authentication step, such as a randomly generated passcode being sent to our email or phone for verification, is also used to bolster security.

# Types of CSRF

As with most bad things, CSRF comes in a range of flavors. Let's look at some of the most common approaches.

## Link-based CSRF 

The attacker creates a malicious link that, when clicked by the victim, causes the victim's browser to send a request to the target web application. Some form of phishing is often necessary to get the malicious link to target users, either through email, instant messaging, social media posts, or even strategically placed ads.

Let's look at an example. Assume that there's a banking website that uses the `GET` method to make requests. The request automatically picks up the logged-in user's cookie session ID. This means that actions such as transferring funds can take place by just entering the URL if the user is logged in. An attacker can simply send a URL to the user that, if clicked, sends a request to the bank website's server to conduct an online funds transfer to the attacker's account. This is illustrated below.  

Learn about cross-site request forgery and its different types.

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

Cross-Site Request Forgery

Overview

What is a CSRF attack?