A rate limiting is used to check if the user session has to be limited based on the information in the session
cache. If user make too many requests within a given time ,
HTTP-Servers has to respond with status code
429: Too Many Requests.
Description:-
I have identified that when Forgetting Password for account , the
request has no rate limit which then can be used to loop through one
request. Which can be annoying to the root users sending mass password
to one email.
Steps To Reproduce The Issue
Go to Forget Password page
Enter the mail where you want to receive the link
Capture that request in BURP.
Send this to Intruder and set parameter at"Accept-Language: en-US,en;q=0.5"
Now go to payload and select number from 1 to 100.
Click on start attack.
If you will receive 100 mails with this , than this is a bug which have to be reported.
Solution -
I Will Recommend to Add A ReCaptcha & Sort Of Something Which
Requires Manual Human Interaction To Proceed Like You Can Add Captcha
Like 2+2=___ so that it cannot be brute forced and you also can have a
limit at the backend for particular number upto 5 times a day user can
request Forget Password Email or Link something like that will prevent
you from someone exploiting this vulnerability
Impact
If You Are Using Any Email Service Software API Or Some Tool Which
Costs You For Your Email This Type Of Attack Can Result You In Financial
Lose And It Can Also Slow Down Your Services It Can Take Bulk Of
Storage In Sent Mail Although If Users Are Affected By This
Vulnerability They Can Stop Using Your Services Which Can Lead To
Business Risk
Redirect means allowing a website to forward the request for the resources to another URL/endpoint. Let’s assume that you make a request to davindertutorials.com and davindertutorials.com can redirect you to another website(new-davindertutorials.com), so you’ll end up at new-davindertutorials.com even though the original request was made for davindertutorials.com. This is called “redirection”. There are different types of redirects in HTTP, check em out below.
Now Lets understand this vulnerability:
Open redirect is basically what the name says, Openly allow Redirects to any website.
URL redirection vulnerabilities found when user redirect to some other url , mainly the attacker url in unsafe way.
An attacker can construct a URL within the application that causes a redirection to an external domain. This behavior is well known for doing phishing attacks against users of the application.
Redirection Status Code - 3xx
300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
307 Temporary Redirect
308 Permanent Redirect
The redirection can happen on the server-side or the client side.
Server-Side: Request to redirect is sent to the server, then the server notifies the browser to redirect to the url specified via the response.
Client-Side: Browser is notified to redirect to the url specified directly without the intervention of the server.
Why is this an issue?
Think about it for a moment, what if davindertutorials.com, a TRUSTED website allows you to redirect to any other website. Then a malicious user can simply redirect davindertutorials.com to attacker.com, and people fall for it all the time believing that it’s trusted, but infact, it’s not. So allowing redirects to any website without a stop in the middle or without a proper notification for the user is Bad.
Explanation
Let’s say there’s a “well known” website - https://example.com/. And let’s assume that there’s a link like
This link is to a sigup page, once you signup, you get redirected to https://example.com/login which is specified in the HTTP GET Parameter redirectUrl.
What happens if we change the example.com/login to attacker.com?
By visiting this url, if we get redirected to attacker.com after the signup, this means we have an open redirect vulnerablility. This is a classic open redirect vulnerability.
Why does this happen?
This happens due to insufficient redirection checks in the back-end, which means the server is not properly checking if the redirect URL is in their whitelist or not.
Here are some examples of vulnerable code
HTML Meta tags can refresh the site with the given url as it’s content and also you can specify the refresh delay time.
How to find them?
Visit every endpoint of the target to find these “redirect” parameters.
View your proxy history, you might find something. Make sure to use filters.
Bruteforcing helps too.
You might uncover many endpoints by reading javascript code.
Google is your friend, example query: inurl:redirectUrl=http site:target.com
Understand and analyze where the redirection is needed in the target application like redirecting to dashboard after login or something like that.
Some tricks to find this bugs
Test for basic modification of the url like target.com/?redirect_url=https://attacker.com.
Try with double forward slashes target.com//attacker.com.
Try target.com/@attacker.com. In this case the interpretation will be like, the target.com is the username and attacker.com will be the domain.
Test for javascript Protocol javascript:confirm(1).
Try target.com/?image_url=attacker.com/.jpg if there’s an image resource being loaded.
Try IP address instead of the domain name.
You can go further in terms of representing the IP in decimal, hex or octal.
You can also try target.com/?redirect_url=target.com.attacker.com to bypass weak regex implementations.
Chinese seperator 。 as the dot - https://attacker%E3%80%82com.
Test for String reverser unicode(“\u202e”) target.com@%E2%80%AE@attacker.com.
No slashes https:attacker.com.
Back slashes http:/\/\attacker.com or https:/\attacker.com.
Different domain redirect_url=.jp resulting in redirection of target.com.jp which is not the same as target.com.
Try some unicode(including emojis) madness t𝐀rget.com or 𝐀ttacker.com(‘𝐀’ is “\uD835\uDC00”).
Exploitation
Phishing
Assume that the target is example.com. It has a password recovery page at example.com/forgot-password. You enter the email and you click on Forgot Password button, and it’ll send you an email with a password reset link, and this link might look like
Reflected cross-site scripting (or XSS) arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.
Suppose a website has a search function which receives the user-supplied search term in a URL parameter:
https://davindertutorials.com/search?term=hello
The application echoes the supplied search term in the response to this URL:
<p>You searched for: hello</p>
Assuming the application doesn't perform any other processing of the data, an attacker can construct an attack like this:
<p>You searched for: <script>/* Bad stuff here... */</script></p>
If another user of the application requests the attacker's URL, then the script supplied by the attacker will execute in the victim user's browser, in the context of their session with the application.
AFFECT OF THE VULNERABILITY If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Among other things, the attacker can:
Perform any action within the application that the user can perform.
View any information that the user is able to view.
Modify any information that the user is able to modify.
Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.
There are various means by which an attacker might induce a victim
user to make a request that they control, to deliver a reflected XSS
attack. These include placing links on a website controlled by the
attacker, or on another website that allows content to be generated, or
by sending a link in an email, tweet or other message.
Because of the external delivery mechanism for the attack means that the impact of reflected XSS is generally less severe than stored XSS, where a self-contained attack can be delivered within the vulnerable application itself.
REAL WORLD EXAMPLE OF THIS VULNNERABILITY:
PUBG's main website https://www.pubg.com has an endpoint that is vulnerable to an injection vulnerability - namely a reflected injection of JavaScript, also known as Reflected Cross Site Scripting (XSS).
Steps To Reproduce:
How this can be done by attacker
Prepare a JavaScript payload that it wants the victim to execute. In this case, for Proof of Concept purposes, our JavaScript code will prompt an alert showing the users' cookies.
alert(document.cookie);
Inject this Javascript code properly into the vulnerable parameter, creating thus a crafted future GET request that will inject the payload.
GET /?p=iqz78'%3e%3cimg%20src%3da%20onerror%3dalert(document.cookie)%3d1%3echplq HTTP/1.1
Host: www.pubg.com
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Referer: https://www.pubg.com/es/feed/
Cookie: _icl_current_language=en; _icl_visitor_lang_js=en-us; wpml_browser_redirect_test=0; __cfduid=de74423d435717d651b1c9e2c63f4acc21575460678
As this injection happens in a GET parameter, the attacker simply needs to send the crafted Link that produces this GET request to the victim and have the victim click it.
Suppose someone try to visit a website lets says "davindertutorials.com" than the request go to the server . But what if the website server is placed in US and I am surfing that website from India . Few minutes earlier my friend who is living near to me accessing that same website . So lets says davindertutorials.com server is in US but is taking services from cloudfare. So cloudfare DNS is holding copy of the page requested by me which is accessed by my friend few minutes earlier is saved in the cache of cloudfare.
Whenever a cache receives a request for a resource, it needs to decide whether it has a copy of this exact resource already saved and can reply with that, or if it needs to forward the request to the application server.
Simplified example of this attack :
> GET /index.html HTTP/1.1 > GET /index.html HTTP/1.1 > Host: example.com > Host: evil.com
Identifying whether two requests are trying to load the same resource can be difficult so requiring that the requests match byte-for-byte is not actually possible so Caches tackle this problem using the concept of cache keys – a few specific components of a HTTP request that are taken to fully identify the resource being requested. In the request above, I've highlighted the values included in a typical cache key in orange.
This means that caches think the following two requests are equivalent, and will happily respond to the second request with a response cached from the first:
GET /blog/post.php?mobile=1 HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 … Firefox/57.0 Cookie: language=pl; Connection: close
GET /blog/post.php?mobile=1 HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 … Firefox/57.0 Cookie: language=en; Connection: close
This means that caches think the following two requests are equivalent, and will happily respond to the second request with a response cached from the first:
So now if you see, attacker have replaced the language in the cache .. so they can also make many other changes as well
To verify that the cache has been poisoned, just load the homepage in a browser and observe the popup.
This vulnerability arise when you give any input to the host parameter and it may reflect back .
Impact
An attacker can use the vulnerability to
construct a request that, if issued by another application user, will
cause JavaScript code supplied by the attacker to execute within the
user's browser in the context of that user's session with the
application.
Real World Example:
Path : /billing-admin/profile/subscription/?l=de
Payload : c5obc'+alert(1)+'p7yd5
Steps to reproduce :
Request Header :
GET /billing-admin/profile/subscription/?l=de HTTP/1.1
Host: www.semrush.com
Accept: /
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Referer: http://www.google.com/search?hl=en&q=c5obc'+alert(1)+'p7yd5
Overview :
The payload c5obc'+alert(1)+'p7yd5 was submitted in the Referer HTTP
header. Payload is copied from a request and echoed into the
application's immediate response in an unsafe way.
In the above example the payload reflect back in the response causing the rise of the vulnerability.
This vulnerability raised when a website uses the Host header when sending out password
reset links. This allows an attacker to insert a malicious host header,
leading to password reset link / token leakage.
Developers often
resort to the exceedingly untrustworthy HTTP Host header (_SERVER["HTTP_HOST"] in PHP or in another languages
There are two main ways to exploit this trust in regular web applications.
The first approach is web-cache poisoning;
manipulating caching systems into storing a page generated with a
malicious Host and serving it to others.
The second technique abuses
alternative channels like password reset emails where the poisoned
content is delivered directly to the target.
Impact
The victim will receive the malicious link in their email, and, when
clicked, will leak the user's password reset link / token to the
attacker, leading to full account takeover.
Example for more understanding
1.) Open up Firefox and Burp Suite.)
2.) Visit the forgot password page (/index.php/login/concrete/forgot_password)
3.) Enter the victim's email address and click Reset and Email Password
4.) Intercept the HTTP request in Burp Suite & change the Host Header to your malicious site / server.
5.) Forward the request and you'll be redirected to your server.
The victim will then receive a password reset e-mail with your poisoned link.
If the victim clicks the link, the reset token will be leaked and the
attacker will be able to find the reset token in the server logs. The
attacker can then browse to the reset page with the token and change the
password of the victim account!
Remediation
Use $_SERVER['SERVER_NAME'] rather than $_SERVER['HTTP_HOST']
Rewriting of links and URLs in cached pages to arbitrary strings by unauthenticated HTTP clients.When the application reflects HTTP Header value back in it's response and it may be possible to poison the server cache. The X-Forwarded-Host is directly reflected as a hyperlink. Than Host Header Attack - Cache Poisoning vulnerability may be there like:
Affected software: ANY site that does not validate HTTP Host: headers.
It is common practice for web programmers and web frameworks to rely on
the value of the HTTP Host header to write links. This is for
convenience, so that the same software will run on localhost, various
testing servers, subdomains, secondary domains, etc, without
modification. For example:
This turns out to be a very, very bad idea in any language.
The HTTP Host header is arbitrary text controlled by the client, but
common practice treats it as though it were a safe environment variable.
HTTP Request
GET / HTTP/1.1
Host: davindertutorials.com
X-Forwarded-Host: test.com
...
....
HTTP Response
HTTP/1.1 200 OK
....
....
....
<li class="SL_hide" title="Get New Relic on your iPad, iPhone, or
Android phone"><a href="http://test.com/mobility">New Relic
for iOS & Android</a></li>
....
Now as you see we are able to see test.com in the response.
Mitigation: DO NOT use the value
of the Host header for anything. If you must, apply very strict filters
to only allow valid FQDNs, and then whitelist the FQDNs you allow.
Treat it as you would any arbitrary data coming from the outside. If
your webserver is configured to output the value of the Host header (as
in the example, and as by default in many webservers), disable that
configuration.
In simple terms if a website x.com is requested and when i change the host to y.com , if I am able to open the host . Than it is a host header attack.
Vulnerability Description:
Open Redirection is sometimes used as a part of phishing attacks that confuse visitors about which web site they are visiting.
How to find this Vulnerability
1. Change host to x.com, Than click on go . If not able to success . than try below method.
2. Change host to x.com and Set X-Forwarded-Host to original domain.com, if still unable to get success , try the below one
3. Do the opposite to step two , Means change host to original domain.com and Set X-Forwarded-Host to original x.com
If you are unable to find success with the above written steps , Than may be the website is secured for this vulnerability.
Remediation:
If possible, the application should avoid incorporating
user-controllable data into redirection targets. In many cases, this
behavior can be avoided in two ways:
Remove the redirection function from the application, and replace links to it with direct links to the relevant target URLs.
Maintain a server-side list of all URLs that are permitted for
redirection. Instead of passing the target URL as a parameter to the
redirector, pass an index into this list.
Example of a Bug Reported:
Vulnerable URL: https://wakatime.com/settings/account?apikeyrefresh=true
Payload: " X-Forwarded-Host: bing.com "
How to reproduce this vulnerability:
An SPF record is a type of Domain Name Service (DNS) record that identifies which mail servers are permitted to send email on behalf of your domain. The purpose of an SPF record is to prevent spammers from sending messages with forged From addresses at your domain.
like : Suppose woodland company have email address as : customersupport@woodland.com , So if I am able to send a mail using that address that means SPF records are not properly set .
Checking Missing SPF:
There Are Various Ways of Checking Missing SPF Records on a website But the Most Common and Popular way is kitterman.com
Enter Target Website Ex: target.com (Do Not Add https/http or www) Hit Check SPF (IF ANY)
If You see any SPF Record than Domain is Not Vulnerable But if you see Nothing Here then "HURRAY! You Found a Bug"
POC:
Once There is No SPF Records. An Attacker Can Spoof Email Via any Fake Mailer Like Emkei.cz. An Attacker Can Send Email From name "Support" and Email: "support@davindertutorials.com" .With Social Engineering Attack He Can TakeOver User Account Let Victim Knows the Phishing Attack but When He See The Email from the Authorized Domain. He Got tricked Easily.
Confidentiality, integrity, and availability, often known as CIA, are the building blocks of information security .
Any attack on an information system will compromise one, two, or all three of these components. Based on which of these components is being compromised the most, efficient security controls can be designed accordingly.
Confidentiality
In layman’s terms, something that is confidential is secret and is not supposed to be disclosed to unintended people or entities. What’s the first thing that comes to your mind that needs to be kept confidential? Probably your passwords and ATM PINs . There may be many parameters and information items that need to be kept confidential during a particular communication. If confidentiality is compromised, it might result in unauthorized access to your systems or severe loss to your privacy!
Integrity
In context of the information security (InfoSec) world, integrity means that when a sender sends data, the receiver must receive exactly the same data as sent by the sender. For example, if someone sends a message “Hello!”, then the receiver must receive “Hello!” . Any addition or subtraction of data during transit would mean the integrity has been compromised.
Availability
Availability implies that information is available to the authorized parties whenever required. For example, consider a server that stores the payroll data of company employees. The finance team wants to access it at of fiscal year-end for some reporting purpose. If the server is able to provide all the requested information to the requestors, then its availability is considered good and healthy. But if the server goes down at all (for any intentional or unintentional reason), and the finance team is not able to retrieve required data in time, then we say that the information availability has been affected or compromised.
During an attack on a computer system, at least one of the three, confidentiality, integrity or availability, is affected or compromised.
Various attacks on Confidentiality, Integrity and Availability
Pentesting means finding vulnerabilities by using various techniques and methods .
Organisations hire consultants who have team of complete auditors who perfrom the pentesting .
Auditors are those who know how to find vulnerabilities and perform exploits as well to check the securities issues .
Auditors perform the task depending upon the agreement signed between the organisation and the auditors .
Based on the agreement , Pentesting will be performed. Just like we have different type of hackings like ... black ,white and grey box .. similarly auditors perform pentesting based on the the rights provided to them.
Types of hacking
External pentesting This type of hacking is done from the Internet against the client’s public network infrastructure; that is, on those computers in the organization that are exposed to the Internet because they provide a public service. Example of public hosts: router, firewall, web server, mail server, name server, etc.
Internal pentesting As the name suggests, this type of hacking is executed from the customer’s internal network.
Black box hacking This mode is applicable to external testing only. It is called so because the client only gives the name of the company to the consultant, so the auditor starts with no information.
Gray box hacking This method is often refer to internal pentestings. Nevertheless, some auditors also called gray-box-hacking an external test in which the client provides limited information on public computers to be audited.
White box hacking White-box hacking is also called transparent hacking. This method applies only to internal pentestings and is called this way because the client gives complete information to the auditor about its networks and systems.
Phases of hacking
Both the auditor and the cracker follow a logical sequence of steps when conducting a hacking. These grouped steps are called phases. There is a general consensus among the entities and information security professionals that these phases are 5 in the following order: 1-> Reconnaissance 2-> Scanning 3-> Gaining Access 4-> Maintaining Access 5-> Erasing Clues Usually these phases are represented as a cycle that is commonly called “the circle of hacking” with the aim of emphasizing that the cracker can continue the process over and over again.
Though, information security auditors who perform ethical hacking services present a slight variation in the implementation phases like this:
Posts
