- From: Norman Szigeti <nszigeti@cmtelematics.com>
- Date: Wed, 10 Jul 2024 16:36:18 +0200
- To: Jim Manico <jim.manico@owasp.org>
- Cc: Abdulrahman Alqabandi <Abdulrahman.Alqabandi@microsoft.com>, public-webappsec@w3.org
- Message-ID: <CABLkURrE-MtVezAGKGOpxceVUi25k+HHx2h7ns=0Q_qu7Zmfsw@mail.gmail.com>
Abdul, thank you for referring to the GitHub issue, this is exactly what I wanted to recommend. I agree with Jim, this feature is good because it's extremely trivial to implement. Adding static nonces to the script tags is much harder, and it cannot be done in a lot of managed environments. Made a more detailed comment in the GitHub issue: https://github.com/w3c/webappsec-csp/issues/658#issuecomment-2220680445 Norman On Wed, Jul 10, 2024 at 8:16 AM Jim Manico <jim.manico@owasp.org> wrote: > A dedicated response header would be a *lot* easier to deploy than static > nonces. > > - Jim Manico > > On Jul 9, 2024, at 11:41 PM, Abdulrahman Alqabandi < > Abdulrahman.Alqabandi@microsoft.com> wrote: > > > Seems to have been brought up at Possibility to block all javascript: > URLs · Issue #658 · w3c/webappsec-csp · GitHub > <https://github.com/w3c/webappsec-csp/issues/658> > > My understanding is that you'd like to be able to specifically block > 'javascript:' JS executions but not other dangerous sinks for compatibility > with legacy code. There was a suggestion in the github link of using static > nonces and that seems like a viable solution for such a scenario. > > Abdul > <Outlook-ojimrcli.png> > ------------------------------ > *From:* Jim Manico <jim.manico@owasp.org> > *Sent:* Tuesday, July 9, 2024 3:14 AM > *To:* Norman Szigeti <nszigeti@cmtelematics.com> > *Cc:* public-webappsec@w3.org <public-webappsec@w3.org> > *Subject:* [EXTERNAL] Re: CSP instruction for disabling javascript URLs > > [You don't often get email from jim.manico@owasp.org. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > I endorse this because it’s extremely trivial for a developer to implement > a dedicated response center to disable JavaScript URLs. And looking at > Google’s research, 1/3 or more of successful attacks are from JavaScript > URLs. I think a dedicated response header to disable JavaScript URL’s is a > simple and fantastic idea that will be easy to implement and dramatically > improve XSS defense. > > CSP is great, but it’s extremely not trivial to implement strict CSP in > legacy websites. > > I also recommend not adding this specifically to CSP because it’s already > overloaded. > > Perhaps: > > X-JavaScript-URI : deny > > - Jim Manico > > > > On Jul 9, 2024, at 11:59 AM, Norman Szigeti <nszigeti@cmtelematics.com> > wrote: > > > > > > Dear group, > > > > I wanted to send an official submission to W3C, but I cannot find the > right way to do it. I wanted to recommend extending the > Content-Security-Policy instruction set with the ability to disable the > "javascript:" pseudo-protocol. A properly written modern website does not > use this kind of URLs, and also it's pretty easy to check if it's required > for a project or not, so it can be easy to implement this security measure > in a lot of websites. And it can be a strong protection against a lot of > XSS attacks. > > > > Thank you in advance for taking this into consideration. > > > > Best Regards, > > Norman Szigeti > >
Received on Wednesday, 10 July 2024 14:36:52 UTC