How the heck does Google Reader do it?
-
@blakeyrat said:
Create a max pixel width and just change the percentage to the pixel width, if it's 100%. Of course if it's like 98% then you're still screwed, but I'm guessing that's pretty rare.
Well I was thinking just blindly halving the percentage value, but I'll think some more about it.@blakeyrat said:
What language are you building your solution in?
CoffeeScript on node.js I implemented my own XML parser, server / REST framework, (soon to come) ORM framework and client-side templating framework for shits and giggles - that's a story for another day though.
-
-
@Arnavion said:
CoffeeScript on node.js I implemented my own XML parser, server / REST framework, (soon to come) ORM framework and client-side templating framework...
The shit.
-
@morbiuswilters said:
The shit.
Well, since you asked so nicely...
I was inspired by Canonical's NIH syndrome when they announced Mir. I decided to set the arbitrary goal to make something I could deploy on a clean node.js on my AWS server without any other library dependencies.
Plus, I'd never written a parser before, and writing it for strings and then modifying it to work with streams was also fun. So hey, I learnt something new. And I got to evaluate IcedCoffeeScript and streamline.js (equivalents of C#5's async/await for JS).
But in the end, it all really boils down to... "Because."
-
@blakeyrat said:
OBJECT - Keep (plus all attributes) (plus all inner tags)
I'd whitelist the inner tags, otherwise someone might try to slip something through that way.
@blakeyrat said:
All Others - Keep
Others I'd remove: base, html, body, meta, canvas, svg, form, any form elements.. I'd still do a whitelist, too. You never know when Google will add a <fuck-yo-shit-up> tag which will allow executing arbitrary Go code.
@blakeyrat said:
Attributes:
alt - Keep
title - Keep
All Others - Removehref?
I highly recommend a whitelist of style attributes. Even CS does this. You don't want people doing position:fixed (even accidentally) and fucking shit up. Even worse, IE7-and-below has the proprietary "expression" keyword in CSS which lets you inject arbitrary JS. I've used this to hijack some extremely large sites that didn't bother validating styles against a whitelist.
One of the best things you can do, from a security perspective, is to have the feed content served from a subdomain. Then include it in your feed app via an iframe. Restrict cookies so they're only good on the root domain, not the content subdomain. So even if someone manages to inject JS into a feed and get around your safeguards, the worst they can do is fuck up the stuff in the iframe and not access anything useful in the actual feed app.
-
@Arnavion said:
...Canonical's NIH syndrome when they announced Mir.
Wow, that's the first time I've heard of Mir.. what the fuck is going on at Canonical?? I expect them to release their own kernel and libc implementation within 2 years.
-
@morbiuswilters said:
I highly recommend a whitelist of style attributes.
I believe he intends to strip out the style attribute completely, since he did say earlier that parsing the attribute would be too much effort. I don't know what kind of feeds he wants to support, but I don't follow any that have content that would be rendered unreadable by the lack of any CSS.@morbiuswilters said:
I'd still do a whitelist, too. You never know when Google will add a <fuck-yo-shit-up> tag which will allow executing arbitrary Go code.
Whoa whoa, get out of my head morbs.
-
@morbiuswilters said:
Others I'd remove: base, html, body, meta, canvas, svg
Whyssat? They all seem harmless to me. EDIT: Well I guess BASE isn't. The rest seem harmless.
@morbiuswilters said:
form, any form elements.
Yup, good catch.
@morbiuswilters said:
I highly recommend a whitelist of style attributes. Even CS does this.
"All Others - Remove" means: remove style attributes altogether.
The only possibly exception might be in images, where height and width styles should be respected, but I'm still tending towards remove on those.
@morbiuswilters said:
Then include it in your feed app via an iframe.
I'm not sure that's practical to do when designing a site with a responsive design. Also remember you're talking about an end result website that would potentially have hundreds of iframes live at the same time-- think about each Fark headline as an iframe, for example. Performance might go into the shitter.
That said, I totally get the benefits of it, and maybe I could do some hybrid where *all* feed items go into the iframe instead of having an iframe for each one? I dunno, I'll think about it.
I work on this project like... 4 hours a week or so.
-
@blakeyrat said:
That said, I totally get the benefits of it, and maybe I could do some hybrid where all feed items go into the iframe instead of having an iframe for each one? I dunno, I'll think about it.
Yeah, that was my thinking, not an iframe for each item.
-
@morbiuswilters said:
@blakeyrat said:
Attributes:
alt - Keep
title - Keep
All Others - Removehref?
src?
-
@morbiuswilters said:
any form elements
Why form elements? Isn't it sufficient to remove the action parameter of the form (and the submit attribute of any buttons inside) to render it useless?
-
@Arnavion said:
@morbiuswilters said:
any form elements
Why form elements? Isn't it sufficient to remove the action parameter of the form (and the submit attribute of any buttons inside) to render it useless?
Why are we disabling forms? What can forms possibly do to exploit your feed reader that links cannot?
-
Maybe also add ref="noreferer" to all anchors.
-
@morbiuswilters said:
Yeah, that was my thinking, not an iframe for each item.
But if the iframe's on a different domain, how do you communicate between the two parts of the solution? How does the "outer" frame tell the "inner" frame, "oh hey, here's 3 new items to display, and also you can remove items from feed Foo because he unsubscribed"?
-
@blakeyrat said:
@morbiuswilters said:
If the iframe is on a subdomain of the parent's domain, then communication between them is allowed.Yeah, that was my thinking, not an iframe for each item.
But if the iframe's on a different domain, how do you communicate between the two parts of the solution? How does the "outer" frame tell the "inner" frame, "oh hey, here's 3 new items to display, and also you can remove items from feed Foo because he unsubscribed"?
-
@Arnavion said:
@morbiuswilters said:
any form elements
Why form elements? Isn't it sufficient to remove the action parameter of the form (and the submit attribute of any buttons inside) to render it useless?Why not form elements? Do they belong in an RSS feed? From a security perspective, justification isn't needed to remove a seemingly-unneeded feature, it's needed to keep it in.
-
@Ben L. said:
Why are we disabling forms? What can forms possibly do to exploit your feed reader that links cannot?
POST?
-
@blakeyrat said:
@morbiuswilters said:
Yeah, that was my thinking, not an iframe for each item.
But if the iframe's on a different domain, how do you communicate between the two parts of the solution? How does the "outer" frame tell the "inner" frame, "oh hey, here's 3 new items to display, and also you can remove items from feed Foo because he unsubscribed"?
-
@morbiuswilters said:
Why not form elements? Do they belong in an RSS feed? From a security perspective, justification isn't needed to remove a seemingly-unneeded feature, it's needed to keep it in.
You're right of course, that form elements don't seem necessary in an RSS feed, and I agree with your mindset about security - I was pointing out a similar thing about anchors. But humor me, if for some reason blakey did want to show form elements harmlessly, would it be sufficient to remove the action and submit attributes?
-
@morbiuswilters said:
@Ben L. said:
Why are we disabling forms? What can forms possibly do to exploit your feed reader that links cannot?
POST?
So you can exploit blakey's fictional feed reader by sending a POST request to it?
What's next, DELETE?
-
@Arnavion said:
But humor me, if for some reason blakey did want to show form elements harmlessly, would it be sufficient to remove the action and submit attributes?
Arguably he wouldn't even have to do that. He might want to make the action absolute so the form would actually work, but otherwise, a form on your own domain has the same permissions as a form on another domain.
-
@Ben L. said:
@morbiuswilters said:
@Ben L. said:
Why are we disabling forms? What can forms possibly do to exploit your feed reader that links cannot?
POST?
So you can exploit blakey's fictional feed reader by sending a POST request to it?
What's next, DELETE?
Doubtful, but why even include it? It's not necessary. It violates a basic principle of security. And ultimately, when someone does discover a 0-day in a major browser that can be triggered by serving untrusted form elements from your own domain, you'll wish you hadn't.
God, the more I read the things people say on this site, the more I start feeling like CS isn't some god-awful piece of shit, but instead is par-for-the-course. Hell, even CS strips out form elements from posts..
-
@morbiuswilters said:
@blakeyrat said:
@morbiuswilters said:
Yeah, that was my thinking, not an iframe for each item.
But if the iframe's on a different domain, how do you communicate between the two parts of the solution? How does the "outer" frame tell the "inner" frame, "oh hey, here's 3 new items to display, and also you can remove items from feed Foo because he unsubscribed"?
Frames securely mediate, by design.
