What bug you want to Report?

A bug report contains device logs, stack traces, and other diagnostic information to help you find and fix bugs in your app.

Authentication Bypass

Authentication Bypass is a dangerous vulnerability which is found in Web-Applications. Attackers can bypass the control mechanisms which are used by the underlying web application like OTP, Captcha, 2FA, Email verification etc.
An Attacker can perform a  complete Account takeover of Victim.


Severity :   High 

Complexity : Easy

From : Remote / External




Impact : An Adversary can carry out Auth Bypass attack and perform an Account Take Over

Affected IP's : IP Address     Port
https://www.example.com/      443



Recommendations :

The application should protect the sensitive actions and validate the verification process of the web application. Restrict the user for any malicious behaviour.
 
 
 
References :

https://hackerone.com/reports/770504
https://hackerone.com/reports/257305
https://hackerone.com/reports/219205

 

No Rate Limit 

No Rate Limit is a type of computer security vulnerability typically found in web applications. No Rate Limit  enables attackers to perform actions on the web application where the attacker can do signup creation, password reset or 2FA of other users. No Rate Limit vulnerability may be used by attackers to bypass access controls such & bruteforce tokens and passwords without any limiting of any requests. There should be protection on the web application for sensitive actions. Attackers send a high number of requests to perform desirable actions to get access to the application or accounts. 

NO RL effects vary in range from petty nuisance to significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner network.





Severity :   High 

POST Request :

Complexity : Easy

From : Remote / External



Impact :An Adversary can carry out No Rate-Limit attack and also can take over the victim Account.
Also, an adversary can manage to login through any other user's account.


Affected IP's : IP Address    Port
https://www.example.com/    443




Recommendations :

There should be a protection on the web application for limiting the users simultaneous requests.

Any user should be Rate limited if He/She sends or races high amount of requests in a significant amount of time.
 
 
 
References :

https://hackerone.com/reports/743545
https://hackerone.com/reports/385381
https://hackerone.com/reports/297359

Cross Site Scripting (XSS) :

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec as of 2007.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page. For more details on the different types of XSS flaws, see: Types of Cross-Site Scripting.




Severity :  High 

Payload : Enter the payload here

Complexity : Easy

From : Remote / External




Impact : An Adversary can carry out XSS attack and also can take the cookie of the Admin and login through Admin Account.
Also, an adversary can manage to login through any other users account with valid session cookies.

Affected IP's : IP Address    Port
https://www.example.com/    443






Recommendations :

Sanitize all the user inputs before executing them, also add XSS protection headers on server and client side.
 
 

References :

https://www.acunetix.com/websitesecurity/cross-site-scripting/
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
https://portswigger.net/web-security/cross-site-scripting

 


Provided by HACKING TRUTH (CLICK HERE)

CSRF

Cross-site request forgery (also known as CSRF) is a web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform. It allows an attacker to partly circumvent the same origin policy, which is designed to prevent different websites from interfering with each other.



Severity :   High 

POST Request :

Complexity : Easy

From : Remote / External




Steps to Reproduce:


1. Victim login their example account first.
2. Attacker send a form/link to victim.
3. If victim click the form/link, A desirable action could happen (eg- Profile Details Update or Email Password)
4. Attacker successfully performs ATO





Impact : An Adversary can carry out CSRF attack to modify the details of a victim and also can take over the victim Account.

Affected IP's : IP Address    Port
https://www.india.gov.in/    443





Recommendations :

This CSRF protection protects the form against Cross-site Request Forgery attacks because an attacker would also need to guess the token to successfully trick a victim into sending a valid request. The token should also be invalidated after some time and after the user logs out.

 
 
 
 
References :

https://owasp.org/www-community/attacks/csrf
https://www.acunetix.com/websitesecurity/csrf-attacks/
https://www.netsparker.com/blog/web-security/csrf-cross-site-request-forgery/

CORS

Cross-origin resource sharing (CORS) is a browser mechanism which enables controlled access to resources located outside of a given domain. However, it also provides potential for cross-domain based attacks, if a website's CORS policy is poorly configured and implemented. CORS can be exploited to trust any arbitrary domain attacker controlled domain name and send the data to it.  Attackers can make an exploit and ask the domain to send data of the victim to the attacker domain.




Severity :  High 

CURL Request : curl “https://example.com/wp-json” -I -H Origin:hackingtruth.in
As you can see when we run the above request in curl we can see these header results in the response.  

Access-Control-Allow-Origin: hackingtruth
Access-Control-Allow-Credentials : true

Complexity : Easy

From : Remote / External





Steps to Reproduce:

1. Enter the domain name example.com in the POC Code shown below and save it as exploit.html and click on exploit button :



Exploit Code :

  
  
  
<html>
<body>
<center>
<h2>CORS POC Exploit>/h2>
<h3>Extract SID</h3>

<div id="demo">
<button onclick="cors()" type="button">Exploit Click here
</button></div>

<script>
function cors() {
var xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function() {
if (this.readyState == 4 && this.status == 200) {
document.getElementById("demo").innerHTML = alert(this.responseText);
}
};
xhttp.open("GET", "https://example.com/wp-json/", true);
xhttp.withCredentials = true;
xhttp.send();
}
</script>

</body>
</html>

  

Affected IP's :

IP Address            Port
https://www.example/    443




Recommendations :

All the REST Apis should be authenticated and the domain should not trust any other domains. Allow only selected, trusted domains in the Access-Control-Allow-Origin header.
 
 
 
References :

https://owasp.org/www-community/attacks/CORS_OriginHeaderScrutiny
https://www.geekboy.ninja/blog/exploiting-misconfigured-cors-cross-origin-resource-sharing/
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Provided by HACKING TRUTH (CLICK HERE)

SSRF

Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing.
In typical SSRF examples, the attacker might cause the server to make a connection back to itself, or to other web-based services within the organization's infrastructure, or to external third-party systems



Severity :   High 

POST Request :

Complexity : Easy

From : Remote / External





Steps to Reproduce:

1. Attacker finds the vulnerable injection point (parameter)
2. Attacker sends a localhost request or request to his controlled domain (eg: Burp collaborator)
3. Attacker is able to scan the internal network or connect to localhost. Also attacker can get a HTTP connection on his controlled domain.
4. Attacker successfully performs SSRF and exfiltrates data if any.




Impact : An Adversary can carry out SSRF attack to scan the internal network, perform sensitive actions, download sensitive files like meta-data etc.


Affected IP's : IP Address    Port
https://www.india.gov.in/    443




Recommendations :

There should be a proper validation and sanitization of any URL's,IP or shortlinks given by the user. More here - https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
 
 
 
References :

https://portswigger.net/web-security/ssrf
https://www.acunetix.com/blog/articles/server-side-request-forgery-vulnerability/

Provided by HACKING TRUTH (CLICK HERE)

SQL Injection

SQL injection is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. It generally allows an attacker to view data that they are not normally able to retrieve. This might include data belonging to other users, or any other data that the application itself is able to access. In many cases, an attacker can modify or delete this data, causing persistent changes to the application's content or behavior.





Severity :   High 

POST Request :

Complexity : Easy

From : Remote / External




Steps to Reproduce:

1. Attacker finds the vulnerable injection point (parameter)
2. Attacker sends a query to retreive the DB Version or DB Name or DB Tables
3. Attacker is able to perfrom successfull SQLi




Impact : An Adversary can carry out SQLi attack to download database,usernames,passwords modify the logic or  perform sensitive actions etc.


Affected IP's : IP Address    Port
https://www.india.gov.in/    443



Recommendations :

Most instances of SQL injection can be prevented by using parameterized queries (also known as prepared statements) instead of string concatenation within the query.


References :

https://portswigger.net/web-security/sql-injection
https://www.acunetix.com/vulnerabilities/web/sql-injection/

Provided by HACKING TRUTH (CLICK HERE)

Broken Link Hijacking

When an web application has any pages, sources, links to external 3rd party services and are broken then the attacker can claim those endpoints to successfully conduct the attack and claim those endpoints on behalf of the target website and impersonate his identity.




Severity :   Medium 

POST Request :

Complexity : Easy

From : Remote / External





Steps to Reproduce:

1. Attacker finds the vulnerable injection point (broken link)
2. Attacker is able to claim the broken link
3. Attacker is succesfully perfrom the BLH Attack





Impact : An Adversary can carry out BLH attack to trick the victim in clicking the link and visiting the resources which are linked to the website, this way attacker can perfrom identify theft and steal credentials.


Affected IP's : IP Address    Port
https://www.india.gov.in/    443




Recommendations :

Fix all the broken links in the web application to any external resources.



References :

https://medium.com/@iamtess5277/what-is-broken-link-hijacking-o-o-872d821da6fd
https://medium.com/@arbazhussain/broken-link-hijacking-burp-plugin-6918d922c3fb
https://hackerone.com/reports/266908

Click Jacking

Clickjacking is an interface-based attack in which a user is tricked into clicking on actionable content on a hidden website by clicking on some other content in a decoy website.



Severity :   High 

POST Request :

Complexity : Easy

From : Remote / External





Steps to Reproduce:


1. Attacker finds the web application is vulnerable to Clickjacking and loads successfully into the iframe of the attacker.
2. Attacker creates a POC with the target.com which loads in the iframe
3. Attacker creates or induces a sensitive action
4. Attacker is able to achieve sesntive action on the targt.com





Impact : Clickjacking is an interface-based attack in which a user is tricked into clicking on actionable content on a hidden website by clicking on some other content in a decoy website.

Affected IP's : IP Address    Port
https://www.india.gov.in/    443



Recommendations :

https://portswigger.net/web-security/clickjacking


References :

https://portswigger.net/web-security/clickjacking





Proof of Concept :


   

 <head>

              <style>

                   #target_website {

                            position:relative;

                         width:128px;

                         height:128px;

                         opacity:0.00001;

                         z-index:2;

                         }

                   #decoy_website {

                         position:absolute;

                         width:300px;

                         height:400px;

                         z-index:1;

                         }

             </style>

            </head>

               ...

            <body>

                <div id="decoy_website">

                 ...decoy web content here...

                 </div>

                 <iframe id="target_website" src="https://vulnerable-website.com">

                 </iframe>

            </body>
  
  
  

Subdomain Takeover

HTML Injection

When an application does not properly handle user supplied data, an attacker can supply valid HTML code, typically via a parameter value, and inject their own content into the page. This attack is typically used in conjunction with some form of social engineering, as the attack is exploiting a code-based vulnerability and a user's trust.




Severity :   Medium 

POST Request :

Complexity : Easy

From : Remote / External




Steps to Reproduce:

1. Attacker finds the vulnerable injection point (parameter)
2. Attacker is able to inject the HTML Tags and it gets executed
3. Attacker is able to perfrom successfull HTML Injection




Impact : An Adversary can carry out HMTLi attack to trick the victim in clicking the link and visiting the website, this way attacker can perfrom identify theft and steal credentials.

Affected IP's : IP Address    Port
https://www.india.gov.in/    443





Recommendations :

Do not allow parsing or execution of HTML tags from the user input.


References :

https://www.acunetix.com/vulnerabilities/web/html-injection/#:~:text=HTML%20Injection%20is%20an%20attack,injection%20of%20certain%20HTML%20tags.
https://www.softwaretestinghelp.com/html-injection-tutorial/

File Inclusion

An attacker can use Local File Inclusion (LFI) to trick the web application into exposing or running files on the web server. An LFI attack may lead to information disclosure, remote code execution, or even Cross-site Scripting (XSS). Typically, LFI occurs when an application uses the path to a file as input. If the application treats this input as trusted, a local file may be used in the include statement.



Severity :   High 

Complexity : Easy

From : Remote / External



Steps to Reproduce:

1. Attacker identfies a vulnerable injection point (parameter)
2. Attacker tries to read and execute the internal file
3. Attacker is successfully able to perfrom File Inclusion Attack




Impact : An Adversary can carry out Directory Listing to gain sensitive information from the target server


Affected IP's : IP Address     Port
https://www.example.com/      443



Recommendations :

The application should have proper whitelist of files and ignore every other filename and path.

 
References :

https://www.netsparker.com/blog/web-security/local-file-inclusion-vulnerability/

Directory Listing

Directory Listing is a vulnerabilty in which the server has misconfiguration and exposes the internal and hidden directories from the server to the public internet.
Sometime an attacker can gain sensitive information from the server like backup files, source code , api keys , password files etc.



Severity :   Medium 

Complexity : Easy

From : Remote / External





Impact : An Adversary can carry out Directory Listing to gain sensitive information from the target server

Affected IP's : IP Address     Port
https://www.example.com/      443


Recommendations :

The application should have proper permissions on sensitive directories and content.
 
 
References :

https://www.acunetix.com/blog/articles/directory-listing-information-disclosure/#:~:text=Directory%20listing%20is%20a%20web,it%20leads%20to%20information%20disclosure.

Disclaimer

What is CSRF

CSRF is stand for cross site request forgery and is a malicious exploit of a website basically attacker use for this to exploit and account takeover where unauthorized commands are submitted from a user that the web application trusts. CSRF Account TakeOver on Live Website
 

How CSRF Works?

Attacker sends a link with email and password to the client(as a victim of attacker) and lets say by phishing

Attacker sends a link which contains the request of a email & password of attacker. lets suppose that link is for www.hackingtruthbank.in then as soon as client which means the victim or user clicks on that links his details will get updated to the hackingtruthbank.in by the server. Server accept the new credentails which is given by client but the client unknowlingly clicked that specific links which contains is that two things so the first thing is a new email and new password which got automatically updated.

Now, the attacker logins with new credentials and successfully does ATO (account takeover) of client. so this how CSRF works. CSRF is a very dangerous vulnerability and can leak to successfully ATO and sometimes in this case the client is unable to login to his own account because you know very well what happend with his account But why because his account is now accessable by the new creds by the attacker.

How are we going to test for CSRF?

As you can see how are we going to test for csrf vulnerability in any website whenever you doing hunting for penetration testing.

He need to make two accounts the first account lets say a victim account and the second one is attacker account now what the attacker is going to do is?

The attacker is going to generate a link let's say the email and password for change then he is going to send that malicious link with updated a email and password account details to the victim to the first account now is the victim interact with thats links and click on that links then he have to check the data it has been updated into the profile or not so let's say the attackers link which contans the first new change functionality which means the name should change to the attacker.

When the victims click on that links and his profile his name first name changes is true from victim to attacker that's means we have successfully achive CSRF or in another dangerous case If the attacker send the links with email attacker@gmail.com and password attacker 12345 and if that gets change them it has account takeover vulnerability.

we will do an ATO either changing email or password or both getting the complete access of the account and making a parmanent log out of the user is consider a vulnerability of extreme savirity so in this case your bug can go to PON savirity.

How can we achieve CSRF to Account Takeover?

Now i am going to quickly signup on this website first.

I have created a account onto this platform and i have got an email we have registered successfully and then we clicked on links whereas we can see that RESET YOUR PASSWORD (on your mail). After clicking on that link we redirect on azafashion.com.

As you can see in this user section there are lot of options available but we will be use a profile section.

When i have clicked on account details here are accounts details as can be seen. This is temporary generated name and at all then i am going to change name of this account and the name is victim account.

Now what i am going to do is. I am going to make attacker account also. So i open a new private window with azafashion.com and create a new account of attacker whereas i change a name like attacker.

But in this let me just capture the request before saving a username.

This is the POST request which is going to the server for changing the profile detail as you can see the user first name is return attacker so the attacker comes to know the website is vulnerable to CSRF we a making a POC (proof of concept) through which he is going to change the details of victims.

Then we generate a CSRF poc with enangement tools in burp suite. so you can see POC has been generated and leave the previous request because our work is done.

Then we just copy this all and paste it with a new file called azafashioncsrf.html

so there is name attacker then let me just change or modify the name attacker to attackerCSRF and as you can see this mail ID is belong to attacker account (see the above section i told you in private window i am creating another new account by attacking with MAIL ID).

So after open it in our browser as you can see there's only submit button appear here.

So as you can see this is a victim browser and not a private window and we click on this button as you can see the status is 200.

then when(victim) we try to reload to his account and the details over will be changed here. So the name field has been changed there is attacker CSRF take over as well as email address has been changed. which means that through the attackers request of edit profile the details of the victim got changed and this is the successful CSRF.

Mitigation

CSRF vulnerabilities can still occur on login forms where the user is not authenticated, but the impact and risk is different. ... Login CSRF can be mitigated by creating pre-sessions (sessions before a user is authenticated) and including tokens in login form.


Use captchas and CSRF-tokens for be sure that the victim is changing the datas knowing that.

Report

Disclaimer