Gain insights into JWT, OAuth2, and OpenID Connect. Learn about HTTPS, encryption, and handshake techniques, and explore foundational concepts in web API security for enhanced application protection.

Web application developers are always on the lookout for ways to secure their applications. It has become the most fundamental part of any web application considering the rise in the number of cyber-attacks. This course will be your handy guide to the basic terminologies and frameworks related to web application security.

 In this course, you will learn what JWT is, how a JWT is created, and what benefits it provides in token-based authentication. You will learn about why HTTPS was introduced and how it revolutionized the way data is transferred using techniques like encryption and handshake. You will also dive deep into the most commonly used authentication and authorization frameworks called OAuth and OpenId Connect. This course will give you a taste of what web API security is all about and will give you the foundation so you can further your learning of application security.

Web Security and Access Management: JWT, OAuth2 & OpenId Connect

## What is CSRF?
Cross-site Request Forgery (CSRF), is an attack that tricks a web browser into executing an unwanted action in an application after a user logs in. It allows an attacker to force a logged-in user to act without their consent or knowledge.

In a CSRF attack, the attacker cannot access the data because the attacker does not have access to the response. This can be devastating, as the attacker can force the user to transfer funds from a banking website or share sensitive information.





## How does CSRF work?

To perform a CSRF attack, a few conditions should be met.
1. Cookie-based session handling – The user has already logged in into the website that is being attacked, and the website relies on cookies to identify the user.


2. No unpredictable request parameters – The requests that perform the malicious action do not contain any parameters whose values the attacker cannot determine or guess. For example, when tricking a user into transfering funds, the attacker must not be required to know the password of the user.
 

### CSRF attack using a `GET` request
Let’s look at an example of a CSRF attack using a `GET` request. Suppose a user, Alex, is a customer of ABC bank. He is logged into the bank website. This means the session is currently active, and login information is maintained in the cookies.



Now, suppose a request to transfer funds looks like this:
```
GET http://abcbank.com/transfer.do?acct=Bob&amount=$500 HTTP/1.1
``` 

The attacker will create a request in which the account details of the attacker will be provided.

```
GET http://abcbank.com/transfer.do?acct=attacker&amount=$500 HTTP/1.1
```

The attacker has created the request. The only thing they need to do now is trick the user into sending this request from their own browser.

The attacker can create a promotional email which it will send to the user. This email will contain a hyperlink as shown below:


```
<a href="http://abcbank.com/transfer.do?acct=attackerA&amount=$500">Get the offer!</a>
```
If the user clicks on the hyperlink then the transaction will go through and money will be transferred to the attacker’s account.

As you can see, the user must already be logged in for this attack to be successful. Otherwise, the user will get a login prompt and become skeptical of the link.


### CSRF attack using `POST` request

In an ideal scenario, the `GET` request is not used for state changes. Normally the state change operations are done through a `POST` request.

In the case of `POST`, the user’s browser sends parameters and values in the request body and not the URL, as in the case of a `GET` request.

Therefore, tricking the user to operate a `POST ` request is a bit difficult. With a `GET` request, the attacker only needs the victim to send a URL with all the necessary information. In the case of `POST`, a request body must be appended to the request.


The attacker can create a website and add a JavaScript code to it. They will then send the link of this website to the user through a phishing email.

When the user clicks on the email, the malicious website will send a `POST` request to the bank application.

The code of malicious website created by the user will be as shown below:


```
<body onload="document.csrf.submit()">
 
<form action="http://abcbank.com/transfer" method="POST" name="csrf">
	<input type="hidden" name="amount" value="500">
	<input type="hidden" name="account" value="attacker">
</form>
```

As soon as this page loads, the hidden form will be submitted, which will, in turn, send the `POST` request.


# What is CSRF?
Cross-site Request Forgery (CSRF), is an attack that tricks a web browser into executing an unwanted action in an application after a user logs in. It allows an attacker to force a logged-in user to act without their consent or knowledge.

In a CSRF attack, the attacker cannot access the data because the attacker does not have access to the response. This can be devastating, as the attacker can force the user to transfer funds from a banking website or share sensitive information.





# How does CSRF work?

To perform a CSRF attack, a few conditions should be met.
1. Cookie-based session handling – The user has already logged in into the website that is being attacked, and the website relies on cookies to identify the user.


2. No unpredictable request parameters – The requests that perform the malicious action do not contain any parameters whose values the attacker cannot determine or guess. For example, when tricking a user into transfering funds, the attacker must not be required to know the password of the user.
 

## CSRF attack using a `GET` request
Let’s look at an example of a CSRF attack using a `GET` request. Suppose a user, Alex, is a customer of ABC bank. He is logged into the bank website. This means the session is currently active, and login information is maintained in the cookies.



Now, suppose a request to transfer funds looks like this:
```
GET http://abcbank.com/transfer.do?acct=Bob&amount=$500 HTTP/1.1
``` 

The attacker will create a request in which the account details of the attacker will be provided.

```
GET http://abcbank.com/transfer.do?acct=attacker&amount=$500 HTTP/1.1
```

The attacker has created the request. The only thing they need to do now is trick the user into sending this request from their own browser.

The attacker can create a promotional email which it will send to the user. This email will contain a hyperlink as shown below:


```
<a href="http://abcbank.com/transfer.do?acct=attackerA&amount=$500">Get the offer!</a>
```
If the user clicks on the hyperlink then the transaction will go through and money will be transferred to the attacker’s account.

As you can see, the user must already be logged in for this attack to be successful. Otherwise, the user will get a login prompt and become skeptical of the link.


## CSRF attack using `POST` request

In an ideal scenario, the `GET` request is not used for state changes. Normally the state change operations are done through a `POST` request.

In the case of `POST`, the user’s browser sends parameters and values in the request body and not the URL, as in the case of a `GET` request.

Therefore, tricking the user to operate a `POST ` request is a bit difficult. With a `GET` request, the attacker only needs the victim to send a URL with all the necessary information. In the case of `POST`, a request body must be appended to the request.


The attacker can create a website and add a JavaScript code to it. They will then send the link of this website to the user through a phishing email.

When the user clicks on the email, the malicious website will send a `POST` request to the bank application.

The code of malicious website created by the user will be as shown below:


```
<body onload="document.csrf.submit()">
 
<form action="http://abcbank.com/transfer" method="POST" name="csrf">
	<input type="hidden" name="amount" value="500">
	<input type="hidden" name="account" value="attacker">
</form>
```

As soon as this page loads, the hidden form will be submitted, which will, in turn, send the `POST` request.


In this lesson, we will discuss Cross-site Request Forgery, how the attack can occur, and what steps can be taken to prevent it.


Getting started with Web Application Security

HTTPS Basics

JSON Web Token

OAuth

OpenID Connect

Conclusion

Cross-site Request Forgery (CSRF)

What is CSRF?

How does CSRF work?

CSRF attack using a `GET` request

Cross-site Request Forgery (CSRF)

What is CSRF?

How does CSRF work?

CSRF attack using a GET request

CSRF attack using a `GET` request