I'm attempting to secure a Fantom web application against Cross Site Scripting (XSS) using Content-Security-Policy (CSP).
For those who don't know, it's a HTTP response header that tells browsers and clients how they should restrict where content is loaded from. For example:
One of the bigger benefits of CSP is being able to disable the dangerous eval() javascript statement as dynamic code execution has always been a cause for concern for XSS attacks.
The only issue is, the core Fantom JS libraries currently make use of eval().
To get Fantom to work with CSP, I can use the following directive:
SlimerDude Wed 3 Jan 2018
I'm attempting to secure a Fantom web application against Cross Site Scripting (XSS) using
Content-Security-Policy
(CSP).For those who don't know, it's a HTTP response header that tells browsers and clients how they should restrict where content is loaded from. For example:
Would tell the browser that for this web page, it should only load scripts from the host server or from google-analytics. For details see:
One of the bigger benefits of CSP is being able to disable the dangerous
eval()
javascript statement as dynamic code execution has always been a cause for concern for XSS attacks.The only issue is, the core Fantom JS libraries currently make use of
eval()
.To get Fantom to work with CSP, I can use the following directive:
But it would be much better if Fantom didn't rely on
eval()
, then I could subsequently drop theunsafe-eval
.Note that in
sys.js
I thinkeval()
is only used in a couple of places:Field.js
-fan.sys.Field.prototype.get()
Method.js
-fan.sys.Method.prototype.invoke()
ObjDecoder.js
-fanx_ObjDecoder.prototype.readSimple()
Do you think these few
eval()
usages in Fantom JS could be refactored out?andy Mon 8 Jan 2018
Ticket promoted to #2667 and assigned to andy
I'm not immediately sure how to remove those; but seems like we should be able to
Lets open a ticket to track