OK, so basically I've put together a very low security log in page (javascript username and passwords) which isn't a big deal cause there isn't really anything it's protecting, I just made a login page for the youth on my church website to view and study Sunday School material. What I'm wanting is to make it so you can't type in the direct html to your "profile" or bookmark it, I want them to have to use the javascript log in. For example, the script will direct bob to his "profile" at bob.html, but I want to only go to bob.html only if it comes from login.html, is there any way to do this without getting extremely complicated? I'm expecting there isn't but I thought I'd ask anyway.
If no server side programming is involved you will have to use a simple JavaScript redirection which is not even considered as a "low-level" security but as a "non-level" security :)
Anyway you can check the referrer with document.referrer and redirect to the main page when its not correct, remember that this is very easy to manipulate by the user.
More details on document.referrer can be found here http://www.w3schools.com/jsref/prop_doc_referrer.asp
if ((document.referrer).indexOf('login.html') > 0 && username=='someone' && password=='pass') {do stuff} else {user did not arrive from login.html or username is wrong or password is wrong}
If this is all from client-side javascript, then you can't do anything that's real security. I'm assuming you know that.
But, you can create a slight obstacle to direct access for the casual viewer by having the link from the login page set a very short expiration cookie (like 1-5 minutes), then go to the profile page and have the profile page have all the profile content hidden by default (via a CSS rule). Then, your javascript can check to see if the cookie is present upon loading and, if so, show the content.
If the viewer tries to go directly to the profile page, the cookie will not exist and the page content will not get shown by the javascript. Obviously, the content is still present in the page so any viewer with any knowledge of how web pages work could still see the content in other ways, but it wouldn't show by default in the browser.
Multiple schemes are possible, like the one presented above by jfriend00.
You can also use rolling URLs.
Say your profile page is at http://example.com/profile/foo. Change it to http://example.com/profile/foo?time=yyMMddhhmm where yyMMdd represents the current date, and hhmm represents the current server time. Then make sure that the server refuses to serve this page if the time doesn't match.
Easy to see what happens if someone bookmarks this link. Their bookmark will work for at most one minute.
Unfortunately, the link on the page also expires in one minute. You can solve this problem that updates the URL roughly every minute, but it is not as straightforward as it may look. You will need to take into account the fact that the time on the user's computer may be different from the server time.
Another way to do it is with a session cookie. Session cookies are good until the browser is closed. They expire automatically when you close it. This is a variant of jfriend00's original answer.
Hope this helps.
Related
I want to store the Referer in a cookie (using GTM) so that I can recall this on my lead form and input the information into a hidden field so the info is stored on my CRM.
I want the referer to provide the Full URL
I want the information to be saved on the first visit and not overwritten as they navigate the website.
I need help with the GTM part and writing this information into the Cookie and not overwriting it with every new page that's loaded on our site.
Lunametrics have created a brilliant way of recreating he utm cookie which will help you store all of this information. Just upload the details in to your GTM
https://www.lunametrics.com/labs/recipes/utmz-cookie-replicator-for-gtm/
Im not attributed to them in any way
You can check document.referrer - if it does not contain the hostname of your own site then you are on a landing page (something like if document.referrer.indexOf('mydomain.com') == -1).
That way you can (reasonably well) determine if this is the first page in the visit, in which case you trigger the tag that sets the cookie.
This is not 100% foolproof, since technically browsers are under no obligation to provide a referrer (also it can be easily spoofed), but AFAIK it works on all major browsers, I don't think there is a better way, and it's quite easy to implement.
I have a very confusing problem.
I have a page which only allow paid users to view it. So if the user is not valid I use a pop up with grey backgroud to block users to view the page however there is a potential flaw with this and if a user is clever he can find a workaround and by using the inspect element bypass the popup. Another solution which comes to my mind is to redirect the user to another page instead of pop up like:
window.location = "http://www.example.com";
However there is a potential problem with this or may be I am wrong on this:
I think this way google bots wont be able to crawl that page since redirection happens however in the first approach google will definitely be able to crawl the page.
Now my question is if I use the first approach is there anyway to stop user from manipulating the popup or is there anyway I can distinguish if a user is browsing the page or google?
Also if I use the second approach will google bot be able to crawl the page?
You can't implement a paid block or any types of truly secure/working blocking on the frontend. I would suggest prevent accessing to that said page on the backend.
There's no real clean and 100% working way to this on the frontend. The user can always bypass.
For google, it will be able to crawl the page since the content is still accessible via the rendered html, as it does not care how the page is shown. It gets access to the content anyway, just like you would by fetching the html via a get request without a browser.
You could indeed just redirect, but still do it on the backend not the frontend.
Your current solution does not make the page private - as you rightly point anyone can manipulate the page using the dev tools, and crawlers can read the whole source anyway. Using server-side scripts to block access, and/or vary the content based on an authorisation token is the only way to secure it properly and ensure that only your legitimate paying users get privileged access.
You state a concern about the inability for Google (and other search engines, I assume) to crawl the page if you employ better security. But your logic is flawed: If you make it so that a google bot can still crawl the page, then by definition it must be readable without authorisation. Anyone could view it in the google cache, and parts of its content could show up in google searches. This means it isn't private. Once that's the case, then what are your users paying for, exactly?
What you might realistically want to do is have a cut-down version of the page that is displayed when the user is not authorised, containing enough information for search engines to get an idea of the overall content, and for visitors to be tempted into paying for the rest. Then if the user logs in, the server recognises that and displays the rest of the content as well when the page refreshes. That appears to be roughly what paid-content news sites do, for instance.
Say, a link to a person is sent to a user via email. If the person is already logged into the webpage in his/her browser, clicking on the link takes him/her to the page. However, if he/she is not logged in, he/she should be asked to login in order to access the page. Is there a way to achieve the above functionality using jquery, javascript?
Yes. Build a back-end authentication system, using AJAX and whatever your server-side language is.
From there, develop a hypermedia-style of content-system, and a modular, "widget"-based application delivery model.
Within your hypermedia responses to login (plus passing whatever relevant path information was gained from the e-mail), either redirect the page to a new page (based on the linked response from the server), or download the widgets requested from the server (for whatever application you're displaying media in), and then stream in AJAX content (again, from a URL dictated by the server-response).
This is about as close as you're going to get to security, in terms of delivering things to the client, in real-time, with authentication.
If you were to load the reports/gallery/game/whatever, and put a div over it, and ask for users to log in, then smart users can just kill the div.
If you include the content, or include the application components (JS files), or even include the links to the JS files which will request and display the content, then clever people are again going to disassemble that, in 20 seconds, flat.
The only way I can see to do this is to have a common request-point, to touch the server, and conditionally load your application, based on "next-steps" URLs, passed to the client, based on successful authorization and/or successfully completing whatever the previous step was, plus doing authentication of some form on each request (REST-based tokens+nonces, or otherwise)...
This would keep the content (and any application-structure which might have vulnerabilities) from the client, until you can guarantee that the client has been properly authorized, and the entire application is running inside of multiple enclosed/sandboxed modules, with no direct access to one another, and only instance-based access to a shared-library.
Is it worth the work?
Who knows.
Are we talking about a NORAD nuclear-launch iPhone app, which must run in JavaScript?
Then no, engineering this whole thing for the next six months isn't overboard.
And again, all of this security falls over as soon as one person leaves themselves logged-in, and leaves their phone on the table (biometric authentication as well, then?).
Are we talking about a gallery or discount-offers that you want to prevent people to log into, so you know that only the invited people are using them?
Well, then an 18-month project to engineer, develop, debug and deploy a system like this is probably going to be overkill.
In this case, perhaps you can just do your best to prevent the average person from stealing your content or using your cut-prices, and accept that people who take the time to dig into and reverse-engineer everything are going to find a way to get what they want, 95 times out of 100.
In that case, perhaps just putting a login div overtop of the page IS what you're going to be looking for...
If you're dealing with, say a company back-end, or with company fiscals or end-user, private-data, or anything of the sort, then aside from meeting legal requirements for collection/display/storage, how much extra work you put into the security of the system depends on how much your company's willing to pay to do it.
If it makes you feel better, there are companies out there that pay $60,000-$150,000 a year, to use JS tracking/testing programs from Adobe. Those programs sit right there, on the webpage, most of the time, for anybody to see, as long as you know where to look.
So this isn't exactly an unknown problem.
Yes it is. By authenticating (login) you can store a "loggedIn" cookie which you have to delete by session end (logout or closing the browser). You can use that cookie to check if somebody is logged in or not. If not logged in, than you can display the login page and send the login request with ajax. Btw it is not a good practice to use hybrid applications like that. It is better to use SPA-s with REST service, or implement this on server side.
I am working with rails applications since some couple of months. Now I am supposed to add a feature to show the welcome message for the first time when user visits the site home page, and not for second time even the user reloads the same page.
How can I achieve this by using jQuery or Javascript?
Simply set a cookie and check for it. If you use one of the usual jQuery cookie plug-ins, then put this script at the bottom of the page:
(function($) {
if (!$.cookie("yourcookiename")) {
$("selector for the message").show();
$.cookie("yourcookiename", "x");
}
})(jQuery);
That looks for the cookie and, if not found, shows content that you've defaulted to being hidden.
It's not perfect, because the user can clear cookies, but it's usually good enough.
Not sure how you define first time, if you just mean registered user then you can record something on your server side.
If you mean anyone, you need firstly define who is this guy, writing a cookie to client browser might work but if they change a browser your message will show up again, record IP on server side might work but if some people sharing internet connection then only one person can really see it in that sub net.
Most of the case using cookie should be fine, or to with HTML5 local storage
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.