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

Because Spain won, jQuery: Novice to Ninja is free for 24 hours

sale.sitepoint.com

Post reply on HN
Print view View original

51–60 of 70 posts

Re: Because Spain won, jQuery: Novice to Ninja is free for 24 hours

#51

Post by sdesol »

varaon wrote: post #49
sdesol wrote: post #40

Earlier quoted context omitted.

Could you elaborate on this or point me to a site that explains the security risks? For my product, I have a web app that does 100% of the rendering in Javascript so I use html() a lot. I adhere by the rule that I don't trust anything that comes from the client so I'm curious to learn what the security problem may be. Thanks.

All you need: http://www.owasp.org/index.php/XSS

Thanks for the link but I really don't see anywhere where it says using something like html() would be a greater risk. The rule of thumb is to sanitize information from untrusted sources. And as long as you adhere to this rule, I really don't see how using html() would pose a security threat. That is unless I'm missing something?

Re: Because Spain won, jQuery: Novice to Ninja is free for 24 hours

#52

Post by tptacek »

sdesol wrote: post #51
varaon wrote: post #49

Earlier quoted context omitted.

All you need: http://www.owasp.org/index.php/XSS

Thanks for the link but I really don't see anywhere where it says using something like html() would be a greater risk. The rule of thumb is to sanitize information from untrusted sources. And as long as you adhere to this rule, I really don't see how using html() would pose a security threat. That is unless I'm missing something?

I think the suggestion is that programmatically creating specific DOM nodes is safer than handing the library a string containing user input and hoping that the browser doesn't interpret it in a way that corrupts the DOM.

Re: Because Spain won, jQuery: Novice to Ninja is free for 24 hours

#54

Post by sdesol »

tptacek wrote: post #52
sdesol wrote: post #51

Earlier quoted context omitted.

Thanks for the link but I really don't see anywhere where it says using something like html() would be a greater risk. The rule of thumb is to sanitize information from untrusted sources. And as long as you adhere to this rule, I really don't see how using html() would pose a security threat. That is unless I'm missing something?

I think the suggestion is that programmatically creating specific DOM nodes is safer than handing the library a string containing user input and hoping that the browser doesn't interpret it in a way that corrupts the DOM.

I certainly agree with this but I think it's misleading to say it increases your chances for xss security threats. I can see it increasing the chances of having a webpage not behave properly across all browsers though.

Re: Because Spain won, jQuery: Novice to Ninja is free for 24 hours

#55

Post by jdeseno »

JenSheahan wrote: post #41

Hi - It's Jen from SitePoint, here. Glad to hear you guys are enjoying the free copy of jQuery:Novice to Ninja! As for marketing emails, we always include an "unsubscribe" link. SitePoint will never sell your email address or your information. Enjoy the freebie!

A nice checkbox 'send me marketing upates' below the email entry box would be really nice. These days most people appreciate an opt-in experience to opt-out.

Re: Because Spain won, jQuery: Novice to Ninja is free for 24 hours

#56

Post by chrislloyd »

gridspy wrote: post #37
watchdogtimer wrote: post #29

Earlier quoted context omitted.

She did. Check out the Sitepoint podcast where they interview the book's authors.

It would suck to have that proposal in print if she said no. Talk about a constant reminder.

Earl was more worried that she wouldn't read it!

Re: Because Spain won, jQuery: Novice to Ninja is free for 24 hours

#58

Post by mhansen »

sdesol wrote: post #54
tptacek wrote: post #52

Earlier quoted context omitted.

I think the suggestion is that programmatically creating specific DOM nodes is safer than handing the library a string containing user input and hoping that the browser doesn't interpret it in a way that corrupts the DOM.

I certainly agree with this but I think it's misleading to say it increases your chances for xss security threats. I can see it increasing the chances of having a webpage not behave properly across all browsers though.

Say some "do_bad_stuff();" got through from some source you just expected to have text. (e.g. this happened for youtube the other day)

If you insert this into the DOM with html(), it will execute the script, doing bad things. If you insert it into the dom with e.g. text(), it won't be interpreted.

Re: Because Spain won, jQuery: Novice to Ninja is free for 24 hours

#59

Post by DrJokepu »

sdesol wrote: post #40
DrJokepu wrote: post #18

Interesting book, I just wish it didn't use the .html() function that much, especially the .html(externalInput) pattern - it's a great way to open XSS (cross-site scripting) vulnerabilities on your page unless you're very careful and the author apparently doesn't warn the reader to be careful.

Could you elaborate on this or point me to a site that explains the security risks? For my product, I have a web app that does 100% of the rendering in Javascript so I use html() a lot. I adhere by the rule that I don't trust anything that comes from the client so I'm curious to learn what the security problem may be. Thanks.

You can do the filtering either on input or output (or both if you want to be very careful). Both works, however I prefer filtering on output because (a) if a new way to conduct an XSS attack is discovered, I only need to update code, not data; (2) if tomorrow HTML gets replaced by a hypothetical future document format, I would need to refilter all my data if I only filter at input.

Re: Because Spain won, jQuery: Novice to Ninja is free for 24 hours

#60

Post by DrJokepu »

mhansen wrote: post #58
sdesol wrote: post #54

Earlier quoted context omitted.

I certainly agree with this but I think it's misleading to say it increases your chances for xss security threats. I can see it increasing the chances of having a webpage not behave properly across all browsers though.

Say some " do_bad_stuff(); " got through from some source you just expected to have text. (e.g. this happened for youtube the other day) If you insert this into the DOM with html(), it will execute the script, doing bad things. If you insert it into the dom with e.g. text(), it won't be interpreted.

You don't even need a script tag. Any tag with event attributes will work, e.g. Hello World!
Post reply on HN