I want to automatically log in to specific websites, e.g. the groupware webinterface at work. My browser (Chrome on Linux, if that matters) saves passwords for me, but I want a complete auto-login, so that I don't even have to click the "login" button anymore.
I have investigated multiple ways to approach this, but none of them has turned out to be satisfying:
1. Use a Tampermonkey JavaScript which clicks the "login" button on the website
I wrote a custom JavaScript which was supposed to just click the "submit" button once I load the login page. Chrome was supposed to fill in the password fields. The idea sounded pretty straight-forward. However, this is bad for 2 reasons: On the one hand, I cannot use Chrome's saved password. Chrome has a policy that the password field already displays the circles, but the password is not actually filled in and is also not accessible from JavaScript until the user has performed a gesture such as clicking (see this Chromium issue), which kind of defeats the purpose of my JavaScript. I could go around this by saving the password in localStorage additionally (security wouldn't be compromised, as the saved passwords are not encrypted either), but this doesn't feel good. On the other hand, this breaks a (imho) significant security feature of Chrome. It is the same feature mentioned above which prevents XSS attacks from stealing login passwords. Because whenever I load the login page, the password would be filled in and it would log me in.
So what I would rather want is a special (if possible local) page which I can bookmark, but which will (probably) never be known to anyone performing an XSS attack on me.
2. Use a local HTML page which loads the login page, fills out the form and logs me in
This is a simple idea and would accomplish my goal, but of course it doesn't work because of the same-origin policy.
3. Use a script/program
This would theoretically work. I could write a program which downloads the login page, reads the form, submits it and then transfers the cookies (or the login URL, if the form uses GET to submit to the browser. However, this would be a major piece of work, especially for the case where the forms use the POST method (I'd have to transfer cookies to a possibly running instance of Chrome).
Plus, I'd have to somehow tie this program to a local webserver or turn it into an extension so I could access it from within my browser. After all, opening a shell and typing a command is not really easier than clicking a login button.
4. Use cookies
This is not really an approach, but I mention it here for completeness' sake. By default, Chrome removes all cookies when I exit the browser. I can configure it to keep the cookies of specific websites so I don't have to log in again when I restart it. Some websites use only session cookies, though, so closing the last tab already (correctly) removes the cookies and I have to login again. As a result, cookies only solve my problem for a few websites, but not all.
So my question is: Is there an easier way to accomplish automatic log-in without having to circumvent security features or write a large program?
P.S.: I know, this is a lot of effort to get around clicking a single button every now and then :)
Related
Some of the secure websites on internet such as banks etc. have disabled "Right-click". I know that it's just for preventing the end-user from accessing "Inspect Element" or the "Toolbox" items. But, on some browsers, just pressing F12 key, or any equivalent might does the job.
So, Is there any way to check the webpage for change in code(HTML,CSS and JS) continously, and redirect them to a warning page, if anyone attempts to tamper the code? or just prevent them before they even try to read the code?
Disabling right-click is the absolute easiest thing to work around. You can never completely rely on a web browser to secure your content. Additionally, most, if not all, major modern web browsers have built in protection against cross-site scripting. These browsers are likely going to be better at detecting these than you are. I would actually suspect any Javascript attempt you make to prevent cross site scripting could actually make your page more vulnerable to it.
Some things you could look into to make your web server safer:
When using forms, consider using an anti-forgery token.
Always validate user input. Your web server sends messages to a client computer which then loads that content into a web browser. A good hacker doesn't even need a web browser to hack your web site. So, you can't assume incoming messages are safe at all. This is why you need to validate all input.
Consider creating honeypots to detect malicious attempts by robots or hackers.
I agree with jeff in the comments above; don't worry about those users because you'll never get security tight enough to thwart everyone. Just worry about the 99%. If anyone says they can prevent all users from modifying browser code it is a lie.
Do your actual processing and logic on the server side, not in browser, and NEVER trust ANYTHING they send you. Assume it is a lie or garbage until you validate otherwise.
Likely no, because that action(starting inspector) occur on different layer of browser functionality, html and javascript simply has no access to that layer. As result it's impossible to prevent that action ( viewing html and javascript of page).
If you would lock all possible actions which open js inspector. I am sure that there ways to lock your event bindings, for instance executing js code prior youth, which make it's impossible to add your own lockers for F12, right click and other actions.
I was just looking at this stackoverflow question: Display web browser settings
And that helps.
But, I'm curious if I can detect certain IE specific settings. I'm thinking some of the stuff in the Advanced Tab (e.g. Is 'Enable Integrated Windows Authentication' on)?
Or that our site was added as a Trusted Site? And within the Trusted Site settings, "Atomatic logon with current user name and password" is set?
I don't want to change them (I get that would be a huge issue that could be exploited). I just want to be able to present to the User:
"Hey, you need these couple of settings checked or unchecked for the site to work properly. Do this: a, b, c ... or Contact your Administrator".
Is this possible?
I don't think you can query these settings from within a web site. Being able to do so might introduce security holes.
I'm sure some settings can be determined by using circumstantial evidence (like if a JavaScript doesn't execute, scripting is probably disabled). But I don't think there is a proper API to poll every setting; I guess the best you can do is serve the user some advice on what to look for. (like, "The xyz symbol in the bottom right bar should show a green checkmark like so.... the abc checkbox in the options dialog should be unchecked... etc")
You can't check the settings directly, but you could test the functionality instead. If you attempt to authenticate with the server and find out you don't have their credentials passed in properly, you know it's not configured right. At this point you could show them your information about how to connect to the site. This would be a better solution anyways, as you're better off testing for features rather than specific settings.
To distill your question down, it looks like you're trying to find out whether IE is configured to automatically send NTLM credentials to your server.
Unfortunately, there's no way to cleanly feature-detect this. My initial thought was to put a JavaScript file in a protected directory that simply set a global variable, and link to that script in the <head>. (<script src="protected-dir/test.js"></script> – protected-dir would be configured only for integrated auth with anonymous auth off.) If the script loads, the variable is set; and if it fails, the variable obviously isn't. Another script on the page could check the variable and show a message if it's not set.
This works flawlessly when everything is configured correctly on a client, but when auto login is off, this causes an ugly 401 dialog to pop up, which is clearly no good. Additionally, a XHR request isn't the answer since the spec specifically says the browser should ask for credentials if it gets a 401.
Sadly, I don't think there's a way to automatically determine if auto login is enabled without causing the 401 dialog to pop up.
I have a requirement to paste text from a textarea into the DOM as a preview area, much like the one you get on Stackoverflow when you make a comment etc.
I allow users to insert any and all html tags, including javascript tags. I know this will allow embedded javascript and flash content etc, but I then remove all of this server side so no other user will see, they just see plain text.
However are there any security issues in letting the user insert these things in there own page?
My guess is there isn't otherwise tools like firebug would be a security risk, but I'm not sure.
However are there any security issues in letting the user insert these things in there own page?
I can't see any - the DOM is freely manipulable in the client's browser, anyway. Whether they do it using a tool like Firebug or your JavaScript function, doesn't matter.
As long as the data isn't shown unfiltered in other users' browsers, I think you're safe doing this.
Actually in rare set of circumstance, it might be an issue. It highly depends on how this particular feature works, but I can imagine making first use of CSRF to 'post' in the preview area some malicious javascript/ajax, and use that to steal cookies, change account password or whatever tickles your fancy.
So the attack would go something like this; I send a user a link to a 'legitimate' website. On that website there is a hidden payload (eg via img tag in case of GET, or hidden iframe with auto-submitting form for POST) which silently redirects the user to your website with the XSS payload, which then will be executed by the user through the injection in the preview area, for instance logging user's cookies, without him ever knowing.
Again it all depends how your preview feature works, and if you for instance use form tokens etc., but the point is that it in fact could be an issue.
I have experienced a weird problem with javascript.
The problem page uses some jQuery code to collect data and it does input checking validation. If the validation is true, it posts to the server. Some of our users reported (10% or maybe a lot less), they could not submit on the website.
We talked with one of the users who had the problem, and were even more confused afterwards.
Tester's PC: XP, IE8, FireFox
The first time he used IE and the JavaScript validation did not fire, he was NOT able to submit data to server neither, because the validation was set to be false by default.
(it is supposed to have a error message showing up if the validation is false)
Afterwards he tested with F.F. (F.F. worked straight away).
Coming back to IE again, the validation script started working and the submit was again successful.
So, after all the tester don't have problem any more, and couldn't replicate neither.
I am wondering if there is any software or program may stop the js file from downloading properly?
Because the page is also hosted in a i-frame in another website, that is why i thinking some antivirus may think this is a across-domain threat and stopped the posting working.
If so how can i do a check to ensure all the required js files are downloaded before user doing a submit?
What else should i look into, since the problem happens on client end only, with no server-end validation yet.
#drachenstern: thanks for the edit
You could disable the submit button, enable it only after jQuery is fully loaded and executed.
For example:
<input type="submit" disabled />
then, in your Javascript,
$(function () {
$('input:submit').attr('disabled', false);
});
However, be advised that
User will not be able to submit
anything on a browser that doesn't
support Javascript
You should not
depend on Javascript to verify the
user content; always validate the
data again on the server-side.
It is possible that there is some delay in loading the javascript on the client sde. anti-Virus "Internet secutiry" products (may) do a lot of checks.
It is highly possible that the internet security product scans a call, and then decides "ok, this is safe" and then the javascript file is downloaded. There might be a delay in this.
How to avoid the situation?
Don't tie your form submit to javascript. Let it happen always, with or without javascript. If javascript is ready the user will have a good experience (immediate validation). If it is not yet ready, the user will still be able to do the submit, do the validation and throw error messages the "traditional" way - by refreshing the page
Make the user wait till the javascript is loaded. You can have a small "loading" icon somewhere in the page to tell the user he has to wait. The user can enter the data, but can't submit yet. In the background, keep checking whether the javascript is loaded (setTimeout and checking for a specific variable). Once it is loaded, you can use javascript validations
A combination of the two: Allow non-javascript submit till you know that javascript is loaded. Once done, use javascript validations.
I would suggest at first that you should always validate everything on the server. The only reason to validate on the client is to make the response to the user faster on bad inputs.
Additionally, to ensure that each file is downloaded and processed, you could always put a global var in each file, then check them in the document proper to see if each variable has been found. It's a crude back but it would work.
You didn't specify what version of IE the user was using, but the problem of the file not being loaded right away in IE sounds normal behavior to me, however quirky. I've run into that many times, and the only solution is a ctrl-F5 for me. I don't know what else to say there. It would be WONDERFUL if we could always have every browser respond the same, but we can't, so we go on. Also, what OS were they doing all this testing on? And What browser do you test on?
What behavior do you see in IE? If you're using IE8 or later, you'll have debug tools for sure, and you could always use FirebugLite to debug your pages in IE without using the IE tools. Then you could see what the page is doing in IE. Perhaps it's throwing a javascript parsing error? Are there any icons on the window chrome in IE that would give a tipoff?
But I think that if you're trying to fix the second paragraph, you're doing it wrong if you're relying on the javascript to process the validations. But I'm just one guy.
I have Drupal 5 site where a button is clicked and it calls a JavaScript function. The function basically builds a string, and then redirects to another page on our site. After clicking the button, sometimes the user gets logged out and sees the "Access Denied" screen, even though they were previously logged in. The page where they are being redirected has the same access restrictions as the previous page, but regardless of that, they shouldn't be getting logged out.
One user has this happen about half the time (the other half it works as it should), and another user has reported always being logged out when clicking that button. However, I'm always able to run it without a hitch on the machines I use, and I suspect it has to do with them using IE6. Has anyone run across this issue before, or have any ideas on what could be causing this? I've searched and posted in the Drupal forum, and searched in this forum, and have had no luck yet.
Many things come to mind.
Is the page being redirected to on the same domain? domain.com and www.domain.com are NOT the same as far as cookies are concerned (depending on how they are set)..
Can you reproduce it 100% reliably in any browser? No offense to your users, but users are liars (or at least bad at reporting technical bugs). I wouldn't trust something a user told me as fact ("oh, well, yeah, I was closing the browser between tries. but that shouldn't matter.").
Is there something running on the server that is clearing out session, or is the session expiration limit set too loo?
Moral: go try and reproduce the issue first, so you can narrow down exactly what it is. I suggest Firebug + Firecookie for debugging Firefox and general cookie problems, and Fiddler2 (a proxy) for debugging IE.
I think to be honest, the best way would be to post the code that's causing this.
Drupal uses PHP sessions to do this, which use cookies... do any of the users have cookies switched off?
There are many things that can be causing this, redirecting do a different domain, something clearing out the sessions (/tmp cleanup?), but usually, I'd put something like this down to the browser.
Ask them if they can still reproduce using another browser (try firefox)... check their cookie security settings, and more.