Hacker News Reader

Comment by eveith | Hacker News Reader

I am not a web development guy, so this question might seem ridiculous: To me, it always seems that there are a lot of hazards in any web development project, security-wise: A number of attacks, be it injections, XSS, etc. When seeing a new web development framework, I always ask myself: Are the basic security concerns known today addressed? How can I make sure that choosing cool web framework in language X doesn't lead me to an unsafe webapp? Perhaps somebody with more knowledge in web development could chime in here and help me; I would really appreciate that.

View on HN

I wrote a long reply, but ended up erasing it and I'll just say that many of these vulnerabilities are due to the programmer using one type (i.e. string) to represent all kinds of data that might be malicious and unsanitized, and then losing track of whether a piece of data is safe for use (e.g. to be sent to DB) or not.

I recommend checking out the Yesod web framework [0], which leverages Haskell's strong type system to provide type-safety and a whole range of nice guarantees, including preventing vulnerabilities like the ones you mentioned.

Spock [1] is another cool web framework also written in Haskell that looks quite promising.

[0]: http://www.yesodweb.com/page/about

[1]: https://www.spock.li

Yesod doesn't prevent all of them. You can use "javascript:" to still do XSS, last time I checked. This is because that kind of content is valid in HTML... but maybe not what you wanted to happen

Content Security Policy headers can be used to prevent XSS attacks. Caveats are, user must be using a modern browser, and you have to move all inline scripts out to a .js file. Read more here: http://content-security-policy.com/

I don't see why javascript: is fundamentally different than other XSS vectors

because for other types of injections Yesod WILL actually properly encode <script> tags and make them <script> which will prevent SOME XSS exploits

but it doesn't prevent all of them

This is not true, at least not anymore.

Yesod uses xss-sanitize [0], and their sanitize function does indeed prevent "javascript:" attempts. They even have a test case for it [1].

Playing around with it in the REPL:

  Prelude Text.HTML.SanitizeXSS Data.Text> sanitize $ pack "<IMG SRC=javascript:alert('XSS')>"
  "<img>"
  Prelude Text.HTML.SanitizeXSS Data.Text> sanitize $ pack "<IMG SRC=\"javascript:alert('XSS')\">"
  "<img>"
  Prelude Text.HTML.SanitizeXSS Data.Text> sanitize $ pack "<IMG SRC=fine>"
  "<img src=\"fine\">"
  Prelude Text.HTML.SanitizeXSS Data.Text> sanitize $ pack "<IMG SRC=\"this is ok too\">"
  "<img src=\"this is ok too\">"

[0]: https://hackage.haskell.org/package/xss-sanitize

[1]: https://github.com/yesodweb/haskell-xss-sanitize/blob/9a9101...

This is actually the million dollar question, not remotely ridiculous. A lot of web frameworks are built with ease of use, productivity, and "fun" for developers in mind, but neglect security at the framework level, instead leaving security to be reimplemented by the devs on every new project.

But the whole point of a framework is to encapsulate all the things that you have to implement for every new web project, so you don't have to keep redoing that every time, and can instead focus dev time on new features and unique elements of each individual site. Securing against common vulnerabilities should be part of that.

There are a few frameworks that get this right, Lift (https://liftweb.net/) being the best I know of, designed to eliminate most of the OWASP Top 10 Vulns (https://www.ibm.com/developerworks/library/se-owasptop10/ind...) using Scala's strong type system and a virtual diff architecture similar to now-in-vogue Javascript frameworks like React. Haskell's Yesod framework is, as mentioned above, another good one in this respect.

Thank you; these answers have been most insightful! I learned quite a lot from browsing the links.

I am writing "answers", plural, because although I post this as an answer to SkyMarshals text, I also mean the replies by aban, peller, and petilon.

The canonical resource I'm aware of is the OWASP project.[0-3] Basically though, always escape user-supplied data (and make sure you're correctly escaping it for the contexts of where it ends up[4]), don't roll your own crypto/authentication, and stick to using battle-tested libraries. (If security matters that much to your app, stick to "boring established framework X" and let other people choose "cool new framework Y".)

[0] https://www.owasp.org/index.php/Category:Popular

[1] https://www.owasp.org/index.php/SQL_Injection_Prevention_Che...

[2] https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_P...

[3] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(...

[4] A good framework, used correctly, should take care of most (all?) escaping for you. For SQL injection, it's the ORM's job. For XSS, anything using a virtual DOM should escape stuff for you (I know React does). CSRF is more to do with session management, which is where using battle-tested auth code comes into play.

Virtual DOM doesn't really have anything to do with preventing XSS. It's done in angular 1 as well.

Really, it's about taint checking [1]. Distrust all sources of content by default that might have seen user input (or that you know have seen user input), and require explicit trust declarations from the developers to remove taints.

When you're about to use the data (e.g. appending to the DOM), you simply check for tainted data and escape is for the context you're in. Most times in the browser, that just means escaping content that might be valid HTML, but there are probably other contexts that require escaping as well.

[1]https://en.wikipedia.org/wiki/Taint_checking

Ah, thanks for the clarification! Today I learned :)

There's also that if you're using React (vue, Angular, et al) with a JSON API (as is usually the case) you've also got CSRF forgery dealt with somewhat automatically as well.

For once, modern implementations are actually really helping security.

In this vein, one thing I'm not seeing (although I haven't finished reading the "book" yet) is built-in CSRF protection.

While not difficult to implement correctly yourself, I've found that applications written on frameworks that don't include this in the box tend to be applications vulnerable to CSRF.

https://github.com/SergioBenitez/Rocket/issues/14

Excellent! I'm glad to see that this is on the roadmap :)

Frameworks vary in how idiot proof they are in terms of security. For example web2py has everything set fairly secure out of the box and you have to go out of your way to break it. Others may require a bit more sense from the developer.

It's a fair question, considering things like Cross Site Scripting (XSS) and Cross Site Request Forgery (CSRF) -- especially the latter -- can be mitigated by using a well constructed and tested framework.

Reply on news.ycombinator.com