Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I learned from suffering my first and last XSS attack

livesshattack.net

Post reply on HN
Print view View original

31–40 of 43 posts

Re: What I learned from suffering my first and last XSS attack

#31

Post by masklinn »

rimantas wrote: post #29
minitech wrote: post #26

Earlier quoted context omitted.

> 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. And how native DOM helps there?

There are relatively few DOM APIs which take a trusted string. innerHTML and outerHTML are two and clearly state that they take HTML so it's no surprise for the stuff you give them to be interpreted thus. But if you use e.g. textContent or createTextNode to insert text into your document, they will correctly sanitise it.

jQuery has text()[0], but because most of its API takes strings to start with, it's very convenient to do the wrong thing and shove untrusted strings into unsafe methods.

[0] http://api.jquery.com/text/#text2

Re: What I learned from suffering my first and last XSS attack

#32

Post by pramodliv1 »

borski wrote: post #25
pramodliv1 wrote: post #21

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.

Check out https://www.tinfoilsecurity.com . It looks for XSS, and about 60 other different types of attacks. (edit: full disclosure, I'm one of the founders)

Thanks, I got an error message. I'll check it out once the site is up!

Re: What I learned from suffering my first and last XSS attack

#33

Post by pramodliv1 »

sahreeg wrote: post #27
pramodliv1 wrote: post #21

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.

Vulnerability scanners are usually premium (paid) products. Some offer free trials such as Qualys: https://www.qualys.com/forms/freescan/ 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, s…

Thank you!

Re: What I learned from suffering my first and last XSS attack

#34

Post by pluma »

laumars wrote: post #30
pluma wrote: post #28

Earlier quoted context omitted.

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…

I wasn't implying dynamically typed languages were worse that statically typed languages. I was just discussing the approach I used to mitigate human error when building web UIs in hope it might inspire other people (or other people might offer additional feedback that inspire improvements in my own framework). It is interesting to see that other frameworks are using similar ideas to my own though. Maybe not surprisi…

The "dynamic typing" remark was directed more at the sibling comment than yours directly.

Re: What I learned from suffering my first and last XSS attack

#36

Post by pramodliv1 »

pramodliv1 wrote: post #32
borski wrote: post #25

Earlier quoted context omitted.

Check out https://www.tinfoilsecurity.com . It looks for XSS, and about 60 other different types of attacks. (edit: full disclosure, I'm one of the founders)

Thanks, I got an error message. I'll check it out once the site is up!

Tinfoil discovered a few errors on my site. Thank you! I wish you hired a designer though :)

Re: What I learned from suffering my first and last XSS attack

#37

Post by JimDabell »

pluma wrote: post #28
laumars wrote: post #14

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…

> 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.

That's good, but it's not ideal as it confuses HTML/unsafe. An unwary developer could output untrusted text "safely" and still open up an XSS vulnerability – because they could be outputting to JavaScript embedded within HTML. Yes, Jinja will encode it as HTML by default, rendering it "safe" in terms of the HTML parser, but that still doesn't make it actually safe.

Example:

    alert("Hello, {{user.name}}!");
By default, Jinja will encode this as HTML, meaning that you can't trick the HTML parser into injecting your HTML. But it is still completely vulnerable to the exact same security vulnerability, except by tricking the JavaScript parser.

We should recognise what's actually the issue at play here. It's not really about whether data is safe or not. It's about correctly encoding data in a manner that's suitable for the context in which it is being output. Sometimes that's HTML, sometimes it's JavaScript, sometimes it's CSS, etc.

Re: What I learned from suffering my first and last XSS attack

#38

Post by jameshart »

I have always been nervous about clicking on links to sites that say 'we were hacked, but we're safe now.' When that link also includes the hubristic 'and we'll never be hacked again,' which paints a target on you big enough for the entire darknet to see... I'm sorry but I'm not clicking on that link.

Re: What I learned from suffering my first and last XSS attack

#39

Post by gcr »

jameshart wrote: post #38

I have always been nervous about clicking on links to sites that say 'we were hacked, but we're safe now.' When that link also includes the hubristic 'and we'll never be hacked again,' which paints a target on you big enough for the entire darknet to see... I'm sorry but I'm not clicking on that link.

The site's giving me a 503 Bad Gateway now, so you might be onto something.

Re: What I learned from suffering my first and last XSS attack

#40

Post by marcosdumay »

JimDabell wrote: post #37
pluma wrote: post #28

Earlier quoted context omitted.

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…

> 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. That's good, but it's not ideal as it confuses HTML/unsafe. An unwary developer could output untrusted text "safely" and still open up an XSS vulnerability…

Yes, Jinja's "safe"/"unsafe" are just "html"/"text" by another name.

One could create the more comprehensive "html"/"css"/"javascript"/"text" set in dynamic languages too, but Jinja doesn't.

Post reply on HN