21–30 of 43 posts
Similar to how Google Page Speed Insights and SEO tools which detect errors such as "You haven't minified your CSS", "You haven't set a title and description for your page" etc.
Earlier quoted context omitted.
I'm not sure the DOM API is safer. innerHtml vs html()
If you're assigning untrusted text to a property called `innerHTML`, you shouldn't be surprised to learn that you're vulnerable to XSS. APIs like jQuery are worse because you end up treating strings as HTML without even realizing it. Example from the article: $("#tail-here").prepend(newlines); There's no hint on that line that the `newlines` variable is interpreted as HTML instead of text.
content
Type: >>htmlStringSome modern tools to mitigate XSS/make XSS virtually impossible: - Content-Security-Policy https://developer.mozilla.org/en-US/docs/Web/Security/CSP/In... - The sandbox attribute on iframes: https://developer.mozilla.org/en/docs/Web/HTML/Element/ifram... XSS is one of the hardest things to keep under control at scale.
A much better way to mitigate XSS/HTML injections is not using string functions to generate HTML. CSP prevents an attacker from executing scripts, but the attacker can still corrupt your HTML.
It's like what ASLR and stack canaries do for buffer overflow vulnerabilities in C/C++. You still should try to avoid writing buffer overflow bugs, but if/when they do happen, the protections mean that the issue will probably just be a denial-of-service issue rather than an issue that lets an attacker execute code on your systems.
Earlier quoted context omitted.
If you're assigning untrusted text to a property called `innerHTML`, you shouldn't be surprised to learn that you're vulnerable to XSS. APIs like jQuery are worse because you end up treating strings as HTML without even realizing it. Example from the article: $("#tail-here").prepend(newlines); There's no hint on that line that the `newlines` variable is interpreted as HTML instead of text.
Pfft. Straight from the documentation of the method: content Type: >>htmlString You could argue that the API is bad for allowing HTML strings as arguments, but it's not really surprising that a function does what it is documented to do. Especially since these are DOM manipulation , not string manipulation functions.
The only native DOM API calls that can get you an XSS vulnerability are sets to `innerHTML`, `outerHTML`, and maybe some few others. Most of the methods for getting things done don't have any possibility of introducing an XSS issue. With jQuery, many methods including every method capable of inserting elements is also capable of introducing an XSS issue depending on the types passed to them. So you when you're reviewing for XSS issues, you have many more places to check, and analyzing the calls to jQuery methods to see if they have the potential for XSS is much more difficult because you have to trace the path backwards from every single call to see what types are set into the variables passed to the methods.
Is there a tool that tries XSS and other common attacks on a web page? Similar to how Google Page Speed Insights and SEO tools which detect errors such as "You haven't minified your CSS", "You haven't set a title and description for your page" etc.
(edit: full disclosure, I'm one of the founders)
Earlier quoted context omitted.
If you're assigning untrusted text to a property called `innerHTML`, you shouldn't be surprised to learn that you're vulnerable to XSS. APIs like jQuery are worse because you end up treating strings as HTML without even realizing it. Example from the article: $("#tail-here").prepend(newlines); There's no hint on that line that the `newlines` variable is interpreted as HTML instead of text.
Pfft. Straight from the documentation of the method: content Type: >>htmlString You could argue that the API is bad for allowing HTML strings as arguments, but it's not really surprising that a function does what it is documented to do. Especially since these are DOM manipulation , not string manipulation functions.
That is exactly what I’m arguing, yes.
> but it's not really surprising that a function does what it is documented to do
It doesn’t have to be surprising or undocumented to be stupid.
Is there a tool that tries XSS and other common attacks on a web page? Similar to how Google Page Speed Insights and SEO tools which detect errors such as "You haven't minified your CSS", "You haven't set a title and description for your page" etc.
Other famous tools are nessus, and accunetix: https://www.tenable.com/products/nessus-vulnerability-scanne..., http://www.acunetix.com/vulnerability-scanner/
These scanners are usually used by security consultants to test a complete internal network of a client.
For a full list, some of which are open source, check this link: https://www.owasp.org/index.php/Category:Vulnerability_Scann...
The HTML framework I created for personal projects has a special string type that cannot be output (nor even compiled) without specifically selecting which format you want the string encoded as (eg HTML, URL, plain text, etc). While this does produce some arguably uglier code and creates a little additional development overhead (ie code fails to compile by default), it has caught numerous instances where I would have…
React and Angular (and maybe Ember too?) similarly auto-escape any strings to be rendered and only provide very explicit ways to circumvent that (in React it's even called "dangerouslySetInnerHTML" and takes an object with a property called "__html" rather than a string[0]).
You can avoid XSS in dynamically typed languages. You just need to make it easier to do the safe thing than the difficult thing.
[0]: I really like React's approach to naming APIs you should think twice about using. For legacy reasons ReactDOM is still bundled as part of React and exposed with a property but the name of that property is "__SECRET_DOM_DO_NOT_USE_OR_YOU_WILL_BE_FIRED" (presumably to prevent React maintainers / Facebook employees from using it).
Earlier quoted context omitted.
Pfft. Straight from the documentation of the method: content Type: >>htmlString You could argue that the API is bad for allowing HTML strings as arguments, but it's not really surprising that a function does what it is documented to do. Especially since these are DOM manipulation , not string manipulation functions.
> You could argue that the API is bad for allowing HTML strings as arguments That is exactly what I’m arguing, yes. > but it's not really surprising that a function does what it is documented to do It doesn’t have to be surprising or undocumented to be stupid.
> You could argue that the API is bad for allowing HTML strings as arguments
That is exactly what I’m arguing, yes.
The HTML framework I created for personal projects has a special string type that cannot be output (nor even compiled) without specifically selecting which format you want the string encoded as (eg HTML, URL, plain text, etc). While this does produce some arguably uglier code and creates a little additional development overhead (ie code fails to compile by default), it has caught numerous instances where I would have…
Python's Jinja templating language has the concept of "safe" and "unsafe" strings. By default all strings are unsafe (meaning they will be escaped wherever they are rendered) and you need to explicitly mark them as safe in order to be able to treat them as HTML. React and Angular (and maybe Ember too?) similarly auto-escape any strings to be rendered and only provide very explicit ways to circumvent that (in React it…
It is interesting to see that other frameworks are using similar ideas to my own though. Maybe not surprising; but at least reassuring to know that my own quirky API design isn't as leftfield as it felt when I was developing it.