Live data from Hacker News

Show HN: Rocket – Web Framework for Rust

rocket.rs

91–100 of 123 posts

Re: Show HN: Rocket – Web Framework for Rust

#92
post #86

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 l…

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.

Re: Show HN: Rocket – Web Framework for Rust

#93
post #92
post #86

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 l…

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…

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

Re: Show HN: Rocket – Web Framework for Rust

#94
post #92

Earlier quoted context omitted.

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…

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 tai…

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

Re: Show HN: Rocket – Web Framework for Rust

#96

Syntax is amazing! Hope (so much) to see it possible on beta soon. Maybe for somebody it's not a new thing, but for me this: struct Message { contents: String, } #[put("/ ", data = " ")] fn update(id: ID, message: JSON ) where message is auto-decoded - it's awesome!

Indeed way cleaner than Iron in terms of parsing query (int) arguments and JSON post data (BodyParser).

Re: Show HN: Rocket – Web Framework for Rust

#98
post #86

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 l…

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

Re: Show HN: Rocket – Web Framework for Rust

#100
post #98
post #86

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 l…

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 syste…

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
Post reply on HN