The Security Risks of HTML5 Development 275
CowboyRobot writes "Local storage is a big change from HTML of the past, where browsers could only use cookies to store small bits of information, such as session tokens, for managing identity. HTML5 changes this with sessionStorage, localStorage, and client-side databases to allow developers to store vast amounts of data in the browser that is all accessible from JavaScript. An attacker could retrieve this data or manipulate the data, which would then get used again later by the application and may be uploaded back to the server to attack others, as well. Another risk comes from using 3rd-party code. Until HTML5, JavaScript was limited to requesting resources from the domain from which it was loaded, but with the addition of cross-origin resource sharing (CORS), this has been changed to allow JavaScript to request resources from different domains. This offers increased functionality but requires strict usage policies or risks being abused."
Shouldn't there be full encryption by default? (Score:4, Interesting)
At the minimum there should be full data encryption at the client level, that's just to start. Then there are other problems to solve (cross site code accessing information that it shouldn't be able to access)... Basically your desktop will have to solve issues that application and database servers have to solve and I can imagine this is a much more difficult task to accomplish. With application and database servers at least there are people, whose JOB it is to ensure security of the client data (from programmers to testers and administrators), but on the client side... it's very very sketchy, the number of potential problems is enormous.
Re:Shouldn't there be full encryption by default? (Score:4, Interesting)
Why the hell is parent modded to -1? roman_mir is spot on. If I'm surfing a website and it wants to store information locally, the web browser should encrypt it for security reasons. As a user, I don't want to have to worry about what information is being written out to my hard drive. Clear text for personal information? Banking information? I've RTFA and it says "[There is] a bank that used example HTML5 code for training developers that put data in permanent storage on the client system as opposed to temporary storage." There are people who say [slashdot.org] that banking institutions still use java applets. Think long and hard about this. Another question: do modern day browsers encrypt cookies? I don't know for sure, but I suspect they don't.
And since I've RTFA, I'm going to take this conversation one level further. This ideology sure sounds like a very fat client to me. If we're going to use "sessionStorage, localStorage, and client-side databases" (as per TFA), why not just use an executable? Write the thing in .NET or Java or C? It would be faster for the client and easier to secure from a programming perspective. There's nothing stopping you from using APIs on the web using these languages. Are you saying it's because we can't trust websites? Then why is HTML5 giving access to "system services, such as camera, microphone, and GPS" and allowing "JavaScript to request resources from different domains"? (Again, this is straight from TFA.) About the only thing it doesn't have is unfettered access to the whole hard drive under the user's permissions. Or does it? I don't know. I'm beginning to wonder about how far HTML5 will allow access and under what conditions. Even if HTML 5 asks for permissions on everything it needs to, what do you think the standard user will say to all the "allow access?" questions?
I'm a programmer, but not a web developer. Maybe this article is full of it and maybe it ain't, but in either case, roman_mir should not be modded down for what he is saying. There are legitimate concerns here that he is trying to raise and he hasn't said anything inflammatory in his post.
Re:How is more insecure than what we have now? (Score:5, Interesting)
there's one thing that's "good" about it - usually all that crap would be stored in a cookie and passed back and forth, back and forth each request. At least now the cookie can be a tiny token to pass to the server and all the session-cached data can be stored locally. At least that's what I hope will happen.
There is a need for local storage, even if its caching data. If you want security, there needs to be built-in support for encrypting the storage and keeping the key in the browser tied to a section of the url of the site you're working with. If that could happen transparently, then we'd have better security than what's we'd get otherwise (you can't use a login as many sites don't have one, and you need to keep each site secure from each other, so you can't even store the key in a cookie in case it gets hijacked as it passes over the network)
Anyway, at least people are thinking security of this stuff from the start, rather than wait for it to be exploited first.
No risks here (Score:4, Interesting)
So... where's the risk? How can my computer be put at risk?
If an app want to use localStorage, firefox prompts me for permision, and only assings 5KiB or something like that tops.
The worst scenario I can picture, is my MANUALLY authorizing literally millons of websites and them filling up my disk.
As for CORS: where's the security issue for the user? CORS is allowed for web hosts that explicitly state they support it. And again, how could that possible expose me?
Re:Real developers don't do web development (Score:5, Interesting)