We want to build an offline capable HTML5 SPA with sensitive business data.
Most likely with knockout.js!
But we have really hard security concerns.
What about encryption? Encryption may be possible. But the appropriate key has to be on the (offline) client side as well. And if you have both the algorithms plus keys on the client side you could also store it unencrypted in local storage.
What about data manipulation? It´s easy to manipulate the DOM or JavaScript objects with tools like Firebug etc.
I really love knockout but it doesn´t feel right for real world business applications.
Any suggestions?
I'm no security expert, but if you use js to encrypt/decrypt client-sde wouldn't you have to store both public and private keys client-side? Effectively neutralizing your whole security model.
I think once you have data client-side there really is no way to keep it fully secure, you have to trust the browser to keep the state private but really to be 100% secure you either have to abandon the web or live with the consequences by redirecting to a page or destroying your state after specific time period, sending partial data to the client and relying on server side to fill in the blanks. In a sense all web pages are offline capable if you don't close the tab. Think of your banking website with all your account activity on the page, I see no distinction between that and offline js from a security point of view.
Re: Data manipulation, this really isn't a KO "feature" but JS allows you to do pretty advanced data manipulation and libraries like linq.js make things so much easier. Not quite sql but respectable none the less.
I think KO is absolutely right for real-world business applications. More broadly the browser/js/html may not be right for the level of security you are after.
Bit of a rant, Hope this helps.
Related
Some people have asked similar questions about protecting HTML5 apps and protecting freemium apps, but not both together. I'm asking this separately because I have the impression (whether right or wrong) that HTML5 is particularly insecure vs native.
I'm working on an embedded HTML5 app I want to monetize using the freemium model, but I'm worried about how to keep its virtual currency and scoring variables from being too easily messed with by the end user, as I fear this could negatively impact revenue if some hacker (no offense intended by the term) were to create a YouTube video or blog posting about an exploit. I think it is pretty unlikely early on for this to happen, but I think vulnerability will matter more with popularity. I'm also worried about with which someone can copy an app.
I though realize both are possible inherently with an app installed on the device.
My questions are:
How easy is it, in your opinion or experience, to mess with an
unobfuscated embedded (not browser dependent) HTML5 app and its Javascript vs a native app with core files based on Java or Objective-C data?/How well does obfuscation work on HTML5 apps vs native obfuscated
apps in terms of data protection?
How difficult is it to obfuscate an HTML5 app vs using something like Proguard on regular Android apps?
Does obfuscation cause HTML5 to noticeably slow down for normal users?
Lastly, do you think it's practical to have an HTML5 app with
freemium features? Or do you personally think it is too vulnerable?
What I'm basically trying to figure out with them is whether HTML5 is particularly vulnerable or hard to protect, at least when compared to protecting native apps. If an obfuscated HTML5 app is as secure or insecure as a regular app, then I guess I'm okay with it.
The only way to prevent cheating (and unlocking freemium items is a kind of cheating) is to move all the relevant game logic to the server. Forget about obfuscation. When it's executed on the clients machine, it's under the control of the user. Obfuscation can slow the user down, but it can't stop someone who is determined to hack it. This doesn't just apply to javascript, it applies to every game client, no matter what programming language it is written in.
A general rule of designing cheat-proof multiplayer games is to never trust the client and do all calculations which are relevant for gameplay on the server.
In my opinion it is better to obfuscate AND never trust the client.
Not only that, I would even compress the obfuscated code and I would add an obfuscated decompressor in the client and/or the server.
The technique is viable and it is what professional companies are using all over the web.
Now, to answer your questions:
It's not easy to mess with a correctly obfuscated code (something
which will require you to compress/crypt even numbers).Professional
hackers won't mess with your code "for sport" unless they're given
money to do so and even in that case, they'll have a hard time doing
it (that's why I don't believe in the "forget about obfuscation" way
of thinking).
Obfuscation works really well in terms of data protection.Your code
becomes unreadable and, to some extent, it can be seen as a
compression algorithm thus it reduces file size and loading times.
Obfuscation is easy if you rely on professional tools which can
obfuscate, for example, JS, html5, css and php all together. It's
harder only if you have to develop such tools.But there exists
open-source software too in the field.
It slows down "normal users" definitely, they feel lost in front of
you code.
It's practical to have an HTML5 app with freemium features but it
all depends on your implementation of such options.
If done correctly as stated above, it's less vulnerable but,
personally, I don't like this business model.
I'm not a Web Developer, and I don't know a lot about the web application frameworks out there.
Recently, however, I got into Wt. It's a web framework written in C++ (that's why I got into it), but what impressed me the most is the idea it's based on.
Its API is different from any web framework I ever heard of (CppCMS, Yii, Django, Pylons, Zope, Drupals, Java Servlets, Struts ...): a new Application object gets created for any user session, and it stays alive until the session expires (only at this point the Application object gets destroied). This Application object works like a desktop window: you put Widgets in it (widgets like forms, links, labels ...); when the user clicks on a link (when the HTTP server receives a new GET/POST request) a function gets called on the object tight to the user session (in a nice Signal/Slot way), which can remove/add/change the widgets, thus changing the page the user will see.
As I said, I'm not very skilled with web frameworks, I develop almost only desktop applications; maybe for this reason I think this paradigm behind Wt is great.
I'd like to know what are the pros and cons of this framework API in respect to the other ones, and if there are other frameworks (also in other languages) based on the same concepts.
Wt is a great framework for its intended range of applications.
Wt is great for :
web apps tightly coupled to a session, i.e.
made to be accessed only by users that are logged in (except the landing page)
display a lot of user-dependent content (so not for a wiki)
relying heavily on state
web apps that need to have a lot of controls/buttons and user input.
For exemple, I plan to write a browser MMORPG. Pages will all be having a state tied to a user, and there will be a lot of buttons. Wt is perfect for that. I used to be a Ruby on Rails developper, and switching to Wt for this kind of app was a great moment. It's increadibly cumbersome to design forms with traditional frameworks that try to enforce pure REST.
Wt would also be perfect for a control interface on some process. For example, an interface allowing your customers to configure their adword campain, etc.
Of course, using Wt is not perfect regarding control and separation, but it allows extremely fast development when you need only the "classic" features (buttons, editors, etc.)
So as a rule of thumb, if you are trying to put a desktop application on the web (which is a great idea, removing the need to deploy and update on your customers' machines), Wt is a good candidate.
Also, if you are interfacing with an existing C++ codebase, Wt has an advantage.
I think this is generally bad idea.
Web application is very different from GUI one and there are many reasons:
99% of the web is about the content rather then about iteration.
You go to web to get or share content rather then to do some real time interaction
like drawing a picture, working with spreadsheet or anything else.
Web is content driven rather then "event driven" interactive application.
This has strong impact on how do you create most of web - you bring information
to user rather then interact with him.
The server and client programming is very different
There are some web GUI applications like e-Mail, Chats clients but to perform well
they require very good separation between the client side written
in high quality Java Script and the high quality server side backend that is used
over AJAX for content retrieval.
Hiding this separation like Wt does or (other known frameworks) lead to crappy
software and generally brings more problems then solutions in long run.
Because it should be very clear separation between server side and client side jobs
as some require real time response and some don't.
When you try to solve all this in one wait for problems. Note, there are client-server
solutions for GUI (see X-Server as example) but unlike web they designed for this
and rather work more like IPC rather then client-server solitions.
The web is stateless most of the time.
Or to be more correct the state usually keeps quite small amount of data.
Creation of instant session object is nice idea until you need to...
Scale up save state in long terms then this model becomes not so good, of course
this not "forced" model by Wt but it is general concept that fits certain concept
and some does not.
Bottom Line
If you want to design good GUI like web application. Start learning JavaScript and use good GUI JavaScript frameworks that fit well to GUI even driven design. Then combine them with some server side API using some interaction RPC model like Json-RPC, XML-RPC and other
AJAX tools.
This is the way to do things right for highly interactive applications.
If your application is more content oriented then most of server side web
frameworks do great job - concentrate on server side with its great tools suitable
for the job.
All in one solution? It just does not work...
Disclosure: I'm developer of CppCMS and I think Wt just goes in wrong way.
ASP.NET is similar; it has the same goal to make web development look like desktop application development.
A passionate discussion from today.
Developer 1: "AJAX is a set of tools,
use it where it really helps, not just
for the sake of it."
Developer 2: "Its almost 2011, we can
build rich desktop like applications
in the browser, we should use AJAX
everywhere and make a single page
application with everything in it an
AJAX powered component."
I can understand things so far. Here's where I don't get it.
Developer 1: "Using AJAX to make a
single page app, we will have to write
our own code to manage bookmarking and
browser back forward buttons"
Developer 2: "No problem, that's
easily doable. It's worth it because
AJAX solves the problems we had with
normal GET/POST, the statelessness.
With a one page AJAX app, you can
maintain context, you don't need
hidden variables, heavy session
management as you would when you moved
between pages"
Is Dev 2 right? Has AJAX really solved problems with how the 'web' normally works?
No.
First of all, there's no problem with how the Web works. It was designed to be stateless, and even with a single page AJAX app, the Web is still stateless.
The problem is with how Developers approach managing state in the stateless environment of the web. Single page AJAX applications definitely make managing state much easier for developers (actually, it sidesteps the problem entirely) that are used to being able to manage state easily in a desktop application.
Just remember, though, that if you have a single page AJAX application and you forget to send the state back to the server for persistence, you lose it...
In my personal opinion, single page AJAX applications also have code management/readability/maintainability issues that far outweigh the state management benefits. I'd rather learn how to properly pass state from page to page in my application that deal with the headache of a single page that contains all of my code.
You answered your own question with: "AJAX is a set of tools, use it where it really helps"
AJAX has solved a lot of problems by streamlining user experience and allowing the developer to control the flow server-side and client-side scripting. There is a development cost to utilizing AJAX to its maximum potential that its viability is dependent on the project, requirements, performance expectations, etc.
Node.js is very likely to revolutionize web development and web scripting as well. If there is a long-term scope to web development projects, keep the cost-benefits of upgrading to future technologies in mind as well.
There is a time and place for everything. Writing web pages to not load a new page AT ALL 90% of the time is not appropriate. Certainly there are exceptions for web applications such as Google Docs etc... but AJAX solves a need, and that is "I only want to update a small portion of my page, I don't need to load the entire page again."
You have to understand the needs of your users with the realization of expectations. If I make a comment, I do not really expect the entire page to load again. It's not necessary. If I want to visit another article on the page then I would expect it to go to a different page entirely.
Do not think of AJAX as an all or nothing solution. It fits specific needs just like traditional web pages do, and the two can be married to perfection if that is understood. Otherwise you end up having to write code for a solution to a problem that does not normally exist.
I've been playing with HTML5 location lookups recently and its relatively straightforward to pull someones location from a device like an iPhone.
I want to write an app that uses location data, but its important that the location be factual. In other words I need to prevent people from authoring a fake post to the backing website / web service with mocked up GPS coordinates.
Is there anyway to collect GPS coordinates from a mobile device using the HTML5 geolocation apis and securely transmit that back to a web service in a way that someone wouldn't be able to author a post with the same data and "game the system" so to speak?
Not without some serious encryption on the payload on the client. Which if there is money involved, someone will reverse engineer and figure out how to create valid payloads themselves. Remember if there is money or fame involved then somebody will think the effort to do something like this is "worth it". If your web service is public and not using some kind of encryption nothing on the client will ensure that someone with a network connection can't sniff your protocol and fake whatever data they want. And SSL won't cut it. Anyone can proxy the SSL connection on their local network decrypt the payload and inspect it to their hearts content.
No. Completely agree with the answer from fuzzy lollipop. If you’re talking to a remote machine, the data can always be faked. Always always. What makes you certain you’re even talking to a mobile device at all? The User-Agent string? Pfft, it can be faked. Talking to a GPS? Pfft, could be coming from a predefined path. Talking to a web browser? Pfft, could be a bot, or some other malware.
And don’t think encryption (i.e. HTTPS) is going to help you. The client could edit any of your HTML, CSS, or JavaScript on-the-fly — take Firebug or Greasemonkey for example.
The reasons why you can’t trust the client are the same as the reasons why exploits such as SQL or HTML injection are so common. Ever heard the phrase “the customer is always right”? Well, the customer may be right, but the client is always untrustworthy.
The system is there to be gamed. As flaws are discovered, you patch them one by one. It’s more like leapfrog, rather than achieving the holy grail. Bruce Schneier’s quip “security is a process, not a product” comes to mind. Asking for a system that “can’t be gamed” is missing the point. What you need to be doing is creating a system where the server sanitises the data, and/or rejects bad data — fuzz testing is not a bad idea, either.
That’s about the best you can do without shipping custom untamperable mobiles to your customers with the OS in ROM, and the inside sealed with epoxy.
I want to design a website but I don't know from where to start.
Is there a beginners' guide to start with?
How much dedication do you hope to provide? If you merely want to design a single website, quickly and dirty, there's a plethora of open source web templates available online, with clean and basic HTML/XHTML design strategies that you could modify, and provide content for.
Such as this and that.
Alternatively, if you would like to design your own websites from scratch and have full technical knowledge in the field (the proper way). Pick up a book or two on HTML/XHTML/XML, with documentation on content management systems, php, etc.
You'd soon find that in the beginning your development would be gradual and at best, slow. If you put in sufficient effort, you would find that you get to the point where you can quickly design sites confidently, which best illuminate your content.
You should be familiar with this and this
Try this Web Design from Scratch
I understand by website you mean some kind of web-app. And by design you mean, not just the page design but the design of the web-app. First, you have to understand the anatomy of a web-app. The major components are:
Database is used to store user and application data for long term. A database provides query functionality (SQL), backup on one installation and restore on another, triggers when a data entry changes, and constraints that must be satisfied by the data tables.
Web Server, also called Http Server hosts the web application.
Web Browser such as Internet Explorer or Firefox.
When a user types a URL into the web browser, the web server forwards the URL to the corresponding web application. The web application performs the needed tasks (which may involve reading or writing into the database) and returns a new html page to the user via www.
Some components of the web application are:
Database access objects are representations of objects that encapsulate interaction with database tables.
Business Logic is the main logic of the application. Here we implement the search functionality using Lucene library, for example.
Action Handler handles a http request received from the user, for example when she types a URL or when she clicks on the "submit" button. These are Http GET and POST requests. The Action Handler uses the business logic to drive the actions.
Data view on the web brower is constructed using some template library (which usually produces javascript user interface code for the web browser). For interactivity one may use Ajax techniques.
Almost all web-apps separate the model, view and controller of a web application. The view deals with the display, the model deals with data and the controller deals with control/functioning. See http://www.uidesign.net/Articles/Papers/UsingMVCPatterninWebInter.html.
Several frameworks implement MVC. The most easy ones to get started are Ruby on Rails and Django (over which an open source social network called Pinax too is written). There are much more comprehensive frameworks and libraries in java too (for a single web appl you may need to join several of these libraries), such as spring, webwork, tapestry, lucene (for search), sitemesh (for page decoration). Many java web apps run on tomcat web server and with mysql database.
I started with http://w3schools.com. Make sure you're using Firefox and the Firebug addon. Get your hands dirty then get familiar with the web design community.
I have CSS Mastery by Andy Budd on my desk and it's a good, readable, short, yet deep guide to CSS.
Don't Make me think has also become my mantra of web design.
Overall, you're going to produce a lot of crap--as I have--before you get good. If you have someone to look over what you're doing that'll be the best help. Personal drive will matter the most in the long run though, so stick with it and keep learning.
Liz Castro has a good book too.