I would like to use session storage to query user data in the database only once and then simply use JS to retrieve it, so I'm thinking about using session storage. My question is next, is that safe?
Please note:
1. JS can't be inserted to pages with forms (forms only accept alphanumeric values) so it can only come from URL
1.1 Query strings like www.website.com/?q=blablabla are not used in php (php doesn't retrieve any data from url)
1.2 Calling js in url with javascript:script... isn't a big concern since the user can only asccess his own data, not to mention that he can already access it - that's the point of user data
1.3 Is there a third way of a user being redirected to the site via a link that contains JS that will than be able to access session storage? i.e.: somthing like - www.website.com/script...
My guess is that only something like 1.3 would be a threat (in addition to that, am I missing something?) but does that even exist? And if so is there a way to prevent it?
Thanks for your time and replys.
You're essentially relying on two things for session storage security:
The browser limiting access only to the javascript on the page from this domain
javascript that is running on the page to be secure
Now there's not a whole lot you can do about No. 1 because that's the vendor's issue and, not pointing at anyone in particular but, most of them are usually pretty good at this kind of thing.
So you can be fairly sure no other code on any other tab, domain, browser or process is going to be able to see your storage object.
However, No. 2 is more difficult, You'll have to evaluate by yourself how secure your page is to script attacks, there's plenty of documentation out there on best practices but you could go on for days. You really need to judge how sensitive the data is versus how much work and possible loss of features it would be to secure against it.
If it's really sensitive data I'd question why you'd risk storing it client side at all and have access only through HTTPS. But you're site should be secured for most scripting attacks because if 3rd party javascript is running session cookies are up for grabs and therefore your server security is compromised too.
Since the session storage can only be read by JavaScript that is running on your page, I think your question boils down to "How can JavaScript be excuted/inserted into my page?" There are two attack methods: XSS, meaning some way to inject JavaScript into your page through posting data to your site. If this data is not filtered, it may insert script tags or JavaScript events into your HTML. There are many ways to do this and to protect against it, so I can't be more specific.
A lesser threat would be to trick the site into displaying or changing information through specially crafted links that call specific actions on your page. This technique is called CSRF. Example: Someone crafts a link to the "change email" page and tricks a user who is logged into clicking this link, this changing the email info in the session storage.
If your application is public, anyone can open the session storage in his browser and look up the names of the keys. So unless they are randomized obscurity offers no protection here.
Related
Background:
I'm a tech writer at our company. I dabble in Javascript from time to time, and I consider my js skill level to be maybe advanced beginner/early intermediate.
Anyway, we have Help content created by Adobe's RoboHelp (version 2017). The Help content is static HTML5 .htm pages. The Help gets installed into a folder as a bunch of static .htm pages on our users' computers when they install our product. The users open our .htm pages in their browser via the file:// protocol.
Our Goal:
On our first intro page of our Help, we're planning on showing a "What's New" .htm file inside of an iframe, but we only want to show it the first time a user accesses the documentation.
What I Know and Have Tried:
I know on a real web server, I'd probably just use cookies to control this. But on a local computer, cookies aren't persistent, and after the session closes, the local cookie storage gets deleted.
I know that Javascript accessing the file system unfettered is a security no no and isn't possible.
I've looked into the FileSystem API but the things I've read indicate that it is dead and not in the standard going forward.
My Question:
Is there some other way in Javascript to have limited trusted access to a single settings file etc for this kind of thing? If so, what is the best / recommended way that keeps the user's computer secure but allows us to store and modify settings in a limited fashion so the user has the best experience?
Note that many of these users probably won't have access to the Internet at all, since their computers will be on a factory floor, so a solution that doesn't require talking back to the Internet is ideal.
I assume most of our users log onto their computers with a standard (non-admin) level login. How many users on the same computer will vary, and I don't have that info, though I think it's likely there will be different shifts that use the same computer.
I'm planning on just storing something simple, like boolean values (ie True/False for if this is the first time they've seen the What's New page etc).
Some questions:
Does a user login? What sort of information is planned on being stored?
How many users will be using the same computer?
It's not strictly secure. I wouldn't store any passwords, and personally identifiable info in localStorage, however there are some caveats ( Storing Credentials in Local Storage ), https://softwareengineering.stackexchange.com/questions/152763/html5-localstorage-and-encrypted-sensitive-data ( however if it's on a computer not connected to the internet, then maybe something simple with encryption, might be ... okay )
Might have a look at localStorage.
https://stackoverflow.com/a/44358718/2026508
https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
I have a website where your able to advertise things on my website. The problem is that people are able to do it more than once. Is there a way that people are allowed to visit the website and when they join back they will be redirected to another page saying you have already advertised. People are still able to use vpn's but i have a way to stop that.
How can i use javascript or php to record the users ip first when the visit the website, But if they leave the website or reload the page they will be redirected to another page saying you have already advertised. Is this to much work?
Technically yes, you could use JS and PHP to grab a user's IP address and work with it in a database but proxies and dynamic IPs would make it a very easy check to circumvent. You can also use PHP to create a persistent cookie to identify the user and his/her actions and see if you're getting a returning visitor who posted an ad, but cookies can easily be deleted.
So it's not that what you're trying to do is too much work, it's that it's fairly easily circumvented and not very reliable. Your best bet is an authentication system that requires a valid login to post an ad, logging what the advertisers do, and creating logic which will disallow spammy behavior based on your logs.
You won't be able to stop abuses by very, very determined users but you can make it harder and make them think twice about whether it's worth investing all that time and effort into spamming on your site when there are bound to be much softer targets, giving you the time to deal with the most egregious cases personally instead of trying to stop a torrent of spammy ads.
You cannot stop people doing that 100% for sure.
if you block their IPs they use proxy.
if you use session they change their browsers or reset it to default.
if you block their hardware like in facebook block hard disk serial again they use vpn servers.
if ..
there is no way bro.
Ask for paying instead of making it for free.
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've been looking for better ways to secure my site. Many forums and Q/A sites say jquery variables and HTML attributes may be changed by the end user. How do they do this? If they can alter data and elements on a site, can they insert scripts as well?
For instance I have 2 jquery scripts for a home page. The fist is a "member only" script and the second is a "visitor only" script. Can the end user log into my site, copy the "member only" script, log off, and inject the script so it'll run as a visitor?
Yes, it is safe to assume that nothing on the client side is safe. Using tools like Firebug for Firefox or Developer Tools for Chrome, end users are able to manipulate (add, alter, delete):
Your HTML
Your CSS
Your JS
Your HTTP headers (data packets sent to your server)
Cookies
To answer your question directly: if you are solely relying on JavaScript (and most likely cookies) to track user session state and deliver different content to members and guests, then I can say with absolute certainty that other people will circumvent your security, and it would be trivial to do so.
Designing secure applications is not easy, a constant battle, and takes years to fully master. Hacking applications is very easy, fun for the whole family, and can be learned on YouTube in 20 minutes.
Having said all that, hopefully the content you are containing in the JS is not "mission-critical" or "sensitive-data". If it is, I would seriously weigh the costs of hiring a third party developer who is well versed in security to come in and help you out. Because, like I said earlier, creating a truly secure site is not something easily done.
Short Answer: Yes.
Anything on the users computer can be viewed and changed by the user, and any user can write their own scripts to execute on the page.
For example, you will up vote this post automatically if you paste this in your address bar and hit enter from this page:
javascript: $('#answer-7061924 a.vote-up-off').click();
It's not really hacking because you are the end user running the script yourself, only doing actions the end user can normally do. If you allow the end user on your site to perform actions that affect your server in a way they shouldn't be able to, then you have a problem. For example, if I had a way to make that Javascript execute automatically instead of you having to run it yourself from your address bar. Everyone who came to this page would automatically upvote this answer which would be (obviously) undesired behavior.
Firebug and Greasemonkey can be used to replace any javascript: the nature of the Browser as a client is such that the user can basically have it do anything they want. Your specific scenario is definitely possible.
well, if your scripts are public and not protected by a server side than the Hacker can run it in a browser like mozilla.
you should always keep your protected content in a server side scripting and allow access by the session (or some other server side method)
Yes a user can edit scripts however all scripts are compiled on the user's machine meaning that anything they alter will only affect their machine and not any of your other visitors.
However, if you have paid content which you feed using a "members-only" script then it's safest if you use technology on the server to distribute your members-only content rather than rely on the client scripts to secure your content.
Most security problems occur when the client is allowed to interact with the server and modify data on the server.
Here's a good bit on information you can read about XSS: http://en.wikipedia.org/wiki/Cross-site_scripting
To put it very simply:
The web page is just an interface for clients to use your server. It can be altered in all possible ways and anyone can send any kind of data to your server.
For first, you have to check that the user sending that data to your server has privileges to do so. Usually done by checking against server session.
Then you have to check at your server end that you are only taking the data you want, and nothing more or less and that the data is valid by validating it on your server.
For example if there is a mandatory field in some form that user has to fill out, you have to check that the data is actually sent to server because user may just delete the field from the form and send it without.
Other example is that if you are trying to dynamically add data from the form to database, user may just add new field, like "admin", and set it to 1 and send the form. If you then have admin field in database, the user is set as an admin.
The one of the most important things is to remember avoid SQL injection.
There are many tools to use. They are made for web developers to test if their site is safe. Hackbar is one for example.
For the longest time I was considering using a Javascript bookmarklet to generate the passwords for the different sites I visit to avoid the problem of "similar passwords everywhere", yet still be portable. However, after reading this paper it became clear to me that using this method would mean that a single malicious page could compromise my whole security.
Now I'm pondering the following solution: a bookmarklet, which would only do one thing: open an URL in a new page with the original URL appended (for example http://example.com/password_man.html?url=slashdot.org). The script located on the page from example.com would do the actual password generation.
Does anybody see any security problem with this approach? While it is less convenient than the original one, as far as I can see, even a malicious page could only see the password it gets and would not have access to sensitive information like the master password. Am I correct in assuming this?
More clarifications:
The generating of the password will be done entirely client-side. The "password_man.html" mentioned in the example above will contain javascript code similar to the one already contained in bookmarklets and it will contain an entry field for your to specify the master password
The interpretation of the "url" parameter will also be done client-side. I'm thinking of hosting this file as a particular revision on my google code account (ie. v1234 of password_man.html), which would provide assurances that I'm not changing the page underneath the users
Also, HTTP/HTTPS is not an issue, since all the processing is done by the client browser, no data is sent back to the server. You might argue that a MITM attack could modify the page so that it sends back the generated password for example (or the master password for that matter) in the case that you are using a clear-text protocol (like HTTP), but if you already have a MITM situation there are other avenues of attack which are easier to do (for example: snooping the password from the request which is submitting it, or snooping the session id, etc)
Update: after searching around and thinking about the problem, I concluded that there is no way this can be done securely within the same page. Even if the bookmarklet would only capture the domain and open up a new window (via window.open), a malicious site could always override window.open, such that it would open a copy of the page which would actually capture the master password (essentially perform a phising attack).
supergenpass sounds very similar to what you're proposing to make.
If requirement for being implemented as bookmarklet is portability, there are existing multi-platform password managers. For example, I'm using Lastpass, it supports all major browsers, also works in Opera Mini, also comes in bookmarklet form.
You may want to pass in a passphrase also, along with the url, that way there is two things that must be known in order to regenerate the password.
If you pass in just the url and it always goes to the same password then only one person can use this application.
The odds that two people will use the same passphrase is unlikely, and you can use the same passphrase for every site.
If you use an https connection then it would be more secure from snooping.
I believe you have some usability issues with your approach, and if you use http connection then you will also be vulnerable to snooping. The fact that someone can get the password by knowing the url means that this is more vulnerable than using the same password on each site, IMO.
Update:
Due to the clarification my answer changes.
Basically, in javascript you can have private members, so that other code can't see the values, unless something like firebug is used, but then the user is the one looking.
This link will help explain this more:
http://www.crockford.com/javascript/private.html
If you put the master passphrase and all related information into here, and do the password generation then no other javascript code can get that information, as you will create setters with no getters.
This should enable you to have a secure password generation page.
If you don't mind a Firefox-centric solution take a look at Password Hasher. There is "portable page" option that allows you to generate a page that can be used with other browsers, but I have only tried it with Chrome
The source for it is available here if you want to adapt it for another browser.
Javascripts PRNGs are usually not cryptographically strong: https://bugzilla.mozilla.org/attachment.cgi?id=349768 ; so if you use to generate passwords, other sites might be able to guess the generated password or even influence the password chosen.