How can I store data on the clients side securely (not viewable/visible) in javascript.
In particular, I want to grab an array from the database with PHP and then use that array for autosuggestion data. Currently I am setting the array as a JS variable, however it can be seen in the html page source code.
I have looked at autosuggestions online and came across: http://www.brandspankingnew.net/specials/ajax_autosuggest/ajax_autosuggest_autocomplete.html
I cannot find where the autosuggestion data is being stored, which is what I want for my script. Help!
No, what you are trying to do is impossible. Javascript is being run by the client and thus the client has absolute control over the data. If you are trying to store a secret in javascript then an attacker can use a debugger to see it in memory. But this is the worst case. Its easier a lot easier to manipulate the traffic with TamperData, or manipulate the javascript directly with Greasemonkey.
If it is sensitive data like usernames or passwords, you shouldn't auto suggest anything. If it is not sensitive data, the AJAX solution from your link is the obvious way to go, but you could easily store it in a cookie if it is not more than 4kb, or in various cookies otherwise.
Related
I want to encrypt my API data so that the user can't see it in the network tab or as plaintext in something like the window.__nuxt__ object.
The way I'm doing this now:
encrypt data in back-end with a secret string (like a password)
send encrypted data to front-end
decrypt it on client-side (using the same password as in the back-end)
Here is the problem: The function that decrypts my data can be found by looking through the bundled JavaScript files in the Browser.
Although the function is obfuscated, it is possible the reverse engineer it. And since the password is stored within the function (it has to be, right? Since I don't have the process.env variables on the client-side) everyone can(theoretically) scrape my data.
What is the best way to prevent this?
I know that the data is visible eventually in the browser. I just don't want it the be visible in plaintext.
I'm using express in the back-end and NuxtJS in the front-end by the way.
There's no way to prevent this. All you can do is make it more difficult.
Ultimately, if the data is visible to the user in the browser, you can just get it from the DOM in memory. All the code to transform the encrypted data into the original information must be supplied if you need the user to see the data.
You can obfuscate the code, but your attacker doesn't even need to reverse engineer it to get the data, they just need to run it.
I've seen several other questions on SO that are similar to this, but none of them are really what I'm looking for, so hopefully this won't be seen as a duplicate.
I have a client-side Javascript/HTML5 web application built with jQuery Mobile. I am finding that performance can be quite slow and it was suggested that having too much going on in the DOM could be the cause. My app does have several data-role="page" divs that could be bulking up the DOM in a single html page. I'm trying to split my app into several html pages to improve performance, but I want the experience to be seamless for the user. This means I will need to pass Javascript variables between the physical html pages within my app.
So far I've seen the following options in my searching:
Use a query string in the url going to the other pages. - I'm not sure I want my users seeing a what could be a rather large and confusing query string in the address bar.
Use server side code like ASP.Net or PHP to handle postback data. - I'm open to this, but I'm not really sure how it would work. I don't want to convert my html pages to aspx or php files. Could I have a simple server side script that could embed the postback data into a regular html file?
Use Cookies to store relevant data. - I'm not to sure of this one either because the majority of my users are in enterprise environments that may limit cookie usage.
Are there any other methods for accomplishing this? At this point, I'm leaning toward some sort of server side processing. If that is the best method, could someone point me in the right direction for figuring out how to do that?
Try out Local Storage or Session Storage http://www.w3schools.com/html/html5_webstorage.asp
Local Storage would be a way to go if you are HTML5 compliant. It will store values, reduce the calls to any server until you are actually ready to update all the info and the info will be present even when the browser is closed; use session storage or JS like this
window.onbeforeunload = function() {
localStorage.removeItem(key);
return '';
};
if you need to clear local storage of sensitive info on closing the browser.
Remember that anything you pass into local storage will come out as a string so you will need to convert it to the appropriate data type when you get the info out of storage.
You'll also be limited to storing 5 megs of data (I believe that is standard) but you probably have other issues if your form requires that much info. :)
Check these out for more info
http://msdn.microsoft.com/en-us/library/bg142799(v=vs.85).aspx
http://dev.w3.org/html5/webstorage/
You could use a POST instead of GET if you're only concern with the GET is the user seeing lengthy querystrings.
Use localStorage. localStorage lets you store values in the browser.
I'm working on a new web app where a large amount of content (text, images, meta-data) is requested via an Ajax request.
No auth or login required for a user to access this.
My concern is that you could easily lookup the data source URL and hit it directly outside the app to get large data. In some ways, if you can do this you could probably scrape the static HTML pages elsewhere that also have this content.
Are there any suggestions on methods to obfuscate, hide, or otherwise make it very difficult to access the data directly?
Example: web app HTML page contains a key that is republished every 30 min. On the server side the data is obfuscated based on this key. In order to get the data outside the app you'd need to figure out the data source but also the extra step of scraping the page for a key every 30 min.
I realize there is no 100% way to stop someone, but I'm talking more about deterrence.
Use sessions in your webapp. Make a note (e.g. database entry or some other mechanism which your server-side code can access) when a valid request for the first page is received and include code in the second page to exclude the data when processing a request without a corresponding session entry.
Obviously the specifics on how to do this will vary between languages, but most robust web platforms will support sessions, largely for this type of reason.
If you are wanting to display real-time data and are concerned about scrapers...if this is a big enough concern, then I suggest doing it with flash instead of JS (AJAX). Have the data display withing a flash object. Flash can make real-time send/receive requests to the server just like AJAX. But the benefit of Flash is that the whole stage, data, code, etc.. are within a flash object, which cannot be scraped. Flash object makes the request, you output the stuff as a crypted string of code. Decrypt it within flash and display from there.
"Are there any suggestions on methods to obfuscate, hide, or otherwise make it very difficult to access the data directly?"
Answers your own question because if the data is worth getting it will be obtained because you are obfuscating is merely making it harder to find.
You could in the server side script processing the ajax and returning the data check where the request came from.
I'm working on a web based form builder that uses a mix of Jquery and PHP server side interaction. While the user is building the form I'm trying to determine the best method to store each of one of the form items before all the data is sent to the server. I've looked at the following methods
Javascript arrays
XML document
Send each form item to the server side to be stored in a session
The good, the bad and the ugly
Depends on your application functionality and requirements, but Javascript would probably be the best way. You can use either arrays or objects or whatever in javascript. It's server independent and it will preserve data over a long period of time as long as client session stays present (browser window doesn't close for whatever reason) but this can be quite easily avoided (check my last paragraph).
Using XML documents would be the worst solution because XML is not as well supported on the client side as you might think.
Server side sessions are good and bad. They are fine if you store intermediate results from time to time, so if client session ends because of whatever reason, user doesn't loose all data. But the problem is that it may as well expire on the server.
If I was you, I'd use Javascript storage and if needed occasionally send JSON serialized results to server and persist them there as well (based on business process storig this data somewhere else than session could be a better solution). I'd do the second part (with sever side combination) only if I would know that user will most probably build forms in multiple stages over a longer period of time and multiple client sessions. but can be used for failure preventions as well. Anyway. Javascript is your best bet with possible server-side interaction.
Preserving data between pages on the client
Be aware that it's also possible to preseve data between pages on the client side. Check sessvars library for this. So even if the page gets refreshed or redirected and then returned all this can be stored on the client side between these events like magic. Marvelous any rather tiny library that made my life several times. And lessened application complexity considerably that would otherwise have to be implemented with something more complex.
I used TaffyDB to store data, and it's just wonderfully easy to implement.
Hope this helps you
You may want to check out PersistJS, which exposes a cross-browser persistent storage object. Of course, being persistent, data stored with this library survives sessions, not just page changes.
The latest version (0.2.0) is here – note the version in the above linked post is 0.1.0.
A combination of #1 (although I'd use objects, not arrays necessarily) and #3 would seem like a good approach. Storing the data locally in the browser (#1) makes it immediately accessible. Backing that up with session-based server-side storage defends you from the page being refreshed; you can magically restore the page just as it was.
For my web application, I need to store form inputs spanning across multiple pages, until I finally process/manipulate them to produce some results (its mostly formatting the data entered and presenting it in some layout). The options I think I have are -
Keep sending user's inputs to the server, store it there in some database, do the final manipulation there only, and show the result.
Store the inputs in browser's storage as the user fills the forms, and finally use this stored data to manipulate and show results.
I very much want to use the second method, and perhaps a possible way is using cookies, but I'm afraid I might just hit some upper limit of cookie data storage. I'm also open to understanding the merits of the first method, or any third method.
thanks.
Use webstorage (you can client-side store around 5MB of text or binary data)
Firefox demo: http://codebase.es/test/webstorage.html
DOM Storage is supported in these web browsers:
Internet Explorer 8
Firefox 2 for sessionStorage, 3.5 for localStorage
Safari 4
Just google for sessionStorage and localStorage objects.
Also modern webkit browsers supports client-side sql.
Edit:
I'm not sure about what you want to do but using AJAX you can store everything in javascript variables and serverside databases or sessions are a good choice.
Hitting the storage limit of the cookie could indicate you are trying to store too much on the client side. It might be prudent to store it serverside, in something like a session. The key to the session could then be stored in a cookie.
An alternative method is to not have the requests span multiple pages, and just store the data on the client side, not as a cookie, but as different form fields and/or text fields (they could be hidden). The merit of such a method is it doesnt hit the cookie limit as you have. It also makes your serverside code easier/cleaner, since it doesn't have to keep track of state (something you'd always have to do if spanning across pages, and thus the reason you are hitting the cookie limit in the first place).
You could use a small Flash Movie to store some data via Flash's Shared Memory Api or have a look at Google Gears.
Maybe also consider, that every byte you store in the cookie have to be transmitted everytime you website makes a request to the server.
Generally cookies have a max size of 4k so you could store quite a bit of data in there.
Be careful with validating all information that lives cookies - all the information resides on a client browser and can easily be manipulated by users of the site at any time.
You didn't say which platform you use. Spring Webflow does exactly the kind of form processing that you want:
http://www.springsource.org/webflow
Even if you don't use Java you could use some of the principles.
Edit: One more drawback of big/complex persistent cookies is that you have to make sure that any new code you deploy is backwards compatible with all the cookies that are out in the wild.
I would suggest storing the data in a session variable until you get to the final step rather than a cookie. I think this would be safer for your data as the user does not have direct access to the data, so you can validate as you go.