Opened 3 years ago
Last modified 3 years ago
#62680 new defect
UI Redressing leads to perform unauthenticated Actions
| Reported by: | ImPRINCE99 (Chirag Prajapati) | Owned by: | |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | website | Version: | |
| Keywords: | Cc: | ||
| Port: |
Description
Hello I am Chirag Prajapati a Certified Penetration Tester and Ethical Hacker my License no is: 10188-161-078-1726. I found a CRITICAL Vulnerability on your website: macports.org
This Vulnerability is about ClickJacking !
INTRODUCTION =============================
Clickjacking, also known as a “UI redress attack”, is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the top level page. It is a malicious technique of tricking a user into clicking on something different from what the user perceives, thus potentially revealing confidential information or allowing others to take control of their computer while clicking on seemingly innocuous objects, including web pages.
DESCRIPTION ================================= The website "macports.org" is vulnerable to clickjacking attack. One of the main impacts is that the domain is containing a user login field, which makes high impact.The server didn't return an X-Frame-Options header which means that this website could be at risk of a clickjacking attack. The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.
STEPS TO REPRODUCE =====================================
make the below simple script and put the vulnerable domain in it. <!DOCTYPE HTML> <html lang="en-US"> <head> <meta charset="UTF-8"> <title>I Frame</title> </head> <body> <h3>clickjacking vulnerability by Chirag Prajapati</h3> <iframe src="https://www.macports.org/" height="550px" width="700px"></iframe> </body> </html> save it as an html file and open in a browser!!
IMPACT =================================
The user assumes that they're entering their information into a usual form but they're actually entering it in fields the hacker has overlaid on the UI. Hackers will target passwords, credit card numbers and any other valuable data they can exploit.
SOLUTION =================================
- Sending the proper X-Frame-Options HTTP response headers that instruct the browser to not allow framing from other domains
Employing defensive code in the UI to ensure that the current frame is the most top level window
- Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set on all web pages returned by your site (if you expect the
page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then you'll want to use SAMEORIGIN, otherwise if you never expect the page to be framed, you should use DENY. ALLOW-FROM allows specific websites to frame the web page in supported web browsers)
REFERENCES
==================================
https://hackerone.com/reports/299009
Looking forward to hearing from you !
Attachments (3)
Change History (15)
Changed 3 years ago by ImPRINCE99 (Chirag Prajapati)
| Attachment: | Macports ClickJacking.html added |
|---|
comment:1 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
| Keywords: | Reporting a Bug removed |
|---|---|
| Type: | request → defect |
www.macports.org doesn't have any forms, does it?
comment:2 follow-up: 6 Changed 3 years ago by ImPRINCE99 (Chirag Prajapati)
Respected Team, As this Vulnerability not only affect on the forms, but also it affect on your Login page, Your ticket chat box etc.
So, to secure this flaw I would really recommend to see some below prevention techniques:
- Framebusting or framebreaking: Before support for new HTTP headers became widespread, website developers were on their own and had to deploy special framebuster (or framekiller) scripts to prevent their pages from being framed. The first framebusting scripts simply checked top.location to make sure this was the current page – if not, top.location was set to self. However, these scripts could easily be blocked from the outer frame or otherwise bypassed, and more elaborate solutions were developed. Even so, numerous ways of bypassing even the most elaborate framebreakers exist, and such scripts should only be used to provide rudimentary protection for legacy browsers. The approach currently recommended by OWASP is to hide the entire body of the HTML document and only show it after verifying that the page is not framed.
- X-Frame-Options: Probably the best solution at present is to use the X-Frame-Options (XFO) HTTP response header in server responses. Originally introduced by Microsoft in Internet Explorer 8 and later formalized in RFC 7034, the X-Frame-Options header is used to specify whether a page can be embedded in a <frame>, <iframe>, <embed> or <object> element. The header supports three possible directives: deny to block all framing attempts, sameorigin to allow framing only by pages of the same origin, or allow-from to allow framing by pages from specified URIs. However, allow-from is unsupported by several browsers (including Chrome and Safari), so if you need to specify sources, you are better off using CSP (see below). For general anti-framing protection, you only need to specify X-Frame-Options: deny or X-Frame-Options: sameorigin in your server’s headers.
- Content-Security-Policy with frame-ancestors: The Content-Security-Policy HTTP header (CSP) was initially developed to protect against XSS and other data injection attacks. However, it also provides a frame-ancestors directive for specifying sources that are permitted to embed a page (in a <frame>, <iframe>, <object>, <embed>, or <applet> element). The syntax is simple:
Proof Of Concept(PoC): please see the attached Video
Changed 3 years ago by ImPRINCE99 (Chirag Prajapati)
| Attachment: | record_2.zip added |
|---|
comment:3 Changed 3 years ago by mf2k (Frank Schima)
I believe this to be spam. "ethical hackers" do not have license numbers.
comment:4 Changed 3 years ago by mf2k (Frank Schima)
| Priority: | High → Normal |
|---|
Changed 3 years ago by ImPRINCE99 (Chirag Prajapati)
| Attachment: | CPTE Certificate.jpg added |
|---|
comment:5 Changed 3 years ago by ImPRINCE99 (Chirag Prajapati)
Respected Team, I am a certified CPTE (Certified Penetration Testing Engineer)
Please see the below attachment
comment:6 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to ImPRINCE99:
As this Vulnerability not only affect on the forms, but also it affect on your Login page, Your ticket chat box etc.
We don't have a login page or a ticket chat box on www.macports.org.
comment:7 Changed 3 years ago by ImPRINCE99 (Chirag Prajapati)
As it should be better If you prevent this Vulnerability, also we can see see that trac.macports.org is Vulnerable too !
So I request you to please patch it as soon as possible.
Respected, Chirag Prajapati :)
comment:8 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
I see that your attached video shows that you can embed the URL of this Trac ticket in an iframe, and your original xhtml attachment shows you can embed www.macports.org in an iframe.
I'm still not entirely clear why embedding a web site in an iframe would be a problem. It's been a standard feature of web browsers for decades.
Our Trac does indeed have forms but is of course a completely separate system from www.macports.org. Still, our Trac does not have a login form (GitHub handles login for us).
We can certainly prevent our Trac and other web sites from being embedded in iframes using the methods you suggest. But if you think embedding a web site in an iframe is in general insecure and should never be allowed, then perhaps it would be more efficient for you to work with the major browser manufacturers to get them to disable this functionality, rather than have to speak with the developers of all web sites about it.
comment:9 Changed 3 years ago by ImPRINCE99 (Chirag Prajapati)
Fine no worries, i reported it to you as a responsible security researcher, but if i m not clear to make you understand that this indeed is a vulnerability, then i am sorry.
I am attaching a reference report to prove my point.
https://hackerone.com/reports/299009
And This was a valid vulnerability, I am attaching my paypal link Paypal Link: paypal.me/Chirag8969
Thanks Regards Chirag Prajapati :)
comment:11 Changed 3 years ago by ImPRINCE99 (Chirag Prajapati)
I never said you have to pay for anything, companies give it as a token of appreciation. So i just did my part. Patch it or not its up to you
Paypal Link: paypal.me/Chirag8969
comment:12 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
We are not a company. We are an open source software project composed of unpaid volunteers.
Proof of Concept (PoC) : Macports ClickJacking.html