[MacPorts] #62680: UI Redressing leads to perform unauthenticated Actions

[MacPorts]

#62680: UI Redressing leads to perform unauthenticated Actions
-------------------------+--------------------
  Reporter:  ImPRINCE99  |      Owner:  (none)
      Type:  defect      |     Status:  new
  Priority:  High        |  Milestone:
 Component:  website     |    Version:
Resolution:              |   Keywords:
      Port:              |
-------------------------+--------------------

Comment (by ImPRINCE99):

 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

-- 
Ticket URL: <https://trac.macports.org/ticket/62680#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS