So you know how you are presented with a login screen and then, you fill it out, and then the browser loads the next page? At this point, somehow the password manager bar pops up for LastPass, 1Password, or some other extension, asking if you want to save the password. How do they know you've just logged in successfully??
Forms are sometimes submitted and other times the js intercepts the form submit and sends AJAX.
The response comes back and may set a new cookie, but sometimes the existing session cookie continues to be used (allows session fixation attacks but some implementations do that).
A new location is loaded or reloaded but sometimes the javascript reloads a portion of the document instead
But somehow these password managers DETECT that I've logged into a site successfully! How? Is it because I entered something in a password field, and then some form was submitted or some network request was sent? But how do they know it was successful?
Anyone familiar with these password managers able to give some useful info?
The reason I ask is that I want to develop an extension that detects when you've logged in and somehow tries to extract your user id from the service. It is for the purposes of sharing your user id with friends automatically, and letting them know (with your permission) what sites you are using a lot.
Any hints on techniques to extract the logged-in user's id on the service would also be helpful.
They aren't actually aware of a successful login in most cases. They are aware that a form with a password field was submitted, and the response was a 200OK. This may still be a page displaying an error message.
As for extracting user IDs, I'm pretty sure you mean profile pages or something similar. That will have to be done on a site by site basis as sites will have their own APIs and route structures.
As someone already answered this question, I will agree with him.
They aren't actually aware of a successful login in most cases. They are
aware that a form with a password field was submitted, and the response
was a 200OK. This may still be a page displaying an error message.
Since browsers watch for the request having a password field in it and the response status, But still you can fool the browsers easily. To get to know about the logged in userid you definitely need backend support / api. It depends on the authentication frameworks used in the back-end. But you can get the form fields easily, but extracting / finding userid from the form fields is a quiet difficult task, In most cases, form will be having only two fields there you can manage to get the userid. But in some cases like banking sites they will send few dummy fields fool such tools, Also many fields will be encrypted in the client itself to protect man in the middle attacks. In some cases userid is different from email, So its difficult task.
They only detect if the form was submitted, and it a code 200 (OK) was returned. They don't necessarily know if you were logged in, but this method works on most websites. They might also detect if a new page was loaded afterwards, since a failed login doesn't usually redirect the user. I have, however, had a prompt to save an incorrect password before.
They can detect your current tab. and each HTML element of that page.
May we they have list of login page case to detect keywords like
login,username,forgot password. and check all keyword to identify this is login page.
They just ready page and even they can read your password (yes) .
If you made request from that page & response will be 200ok it means your password is correct.
Whenever to request to server with username and password the server checks these two entry into their database and the server will found your data it will return response code 200 and using AJAX success call back script will catch the response code and will show successful message.
and also return some sort of information you can store into localStorage of browser or into cookie for further use.
I have created a couple of pages static HTML and form: So when form is submitted it goes to second page.
Let's test
<form action="test1.html">
<input type="text" />
<input type="password" />
<input type="submit" />
</form>
</body>
Chrome don't bothered anything happened. While firefox has given a popup to save password even when form is submitted to an error page.
So firefox only looks for a form submitted with a password field and asks for save password popup box.
If want to create an extension which can check wheather user is successfully logged-in and then you want to ask for password remember popup. For that you have to check for server response. I couldn't create a dynamic page to to proof read it with browser example.
Related
So basically my req is to hide 2 fields username and password in a form from viewing it in console log. So what i am planning to do is to listen to event console log and when it executes i remove the values from username and password.
How can i do it? i am also using jquery in my page.
Thanks
You can't do that, and you shouldn't try. Never expose sensitive data like passwords like this.
No you cannot hide these data, because javascript is client-side.
Despite of the advises you received, Facebook uses this system and expose in browser username and password by accessing https://www.facebook.com/login.php?login_attempt=1&lwv=110 when you try to connect, along with all inputs from your form. This procedure is often used before submitting for different reasons: verify email if it is not duplicate, how many login attempts were...
As long as you have SSL connection the only user that can see username, email or password in console is the one who enters these sensitive data in the form so it is not a threat.
The application I'm working on relies on many popups. Those popups rely themselves on query strings. If someone can just type the url in the browser address bar, the page will throw an error as the query strings values are dynamically constructed.
function myFunction(id)
{
window.open("mypopup.aspx?id=" + id);
}
Is there a why to prevent the page from displaying if the requester of the page is not a Javascript? If someone type something like:
https://mycompanyname.com/path/mypopup.aspx
It shouldn't let the user do so. Or, at least check whether the requester is not javascript so I can display a message or redirect the user to a different page? Otherwise, without all those pieces of data needed to construct a request, the page will throw an exception.
Thanks for helping.
Validate the query string directly in myPopup.aspx, if something is missing just redirect or display a message.
Use the Request.QueryString collection to validate in myPopup.aspx.
There is no easy way to validate if the request came from javascript as far as I know. You could try creating a token to validate that the sender is the one you expect, but if you only need to validate the parameters, no need to worry about who is sending the request.
The page cannot differentiate how it was requested, if both requests come from a same browser.
However, you can include in query string to differentiate them.
For example,
window.open("mypopup.aspx?request=javascript&id=" + id);
If a user intentionally type in https://mycompanyname.com/path/mypopup.aspx?request=javascript, so be it. I won't worry about it.
Popups are browser windows too. So it will be tricky to check if the window requesting the page is normal window or popup.
You should restrict the users to see on what url the popup is being opened you can hide the address bar. So user can not copy or know the what's in the url.
window.open('/pageaddress.html','winname','directories=no,titlebar=no,toolbar=no,location=no,status=no,menubar=no,scrollbars=no,resizable=no,width=400,height=350');
Setup a token based validation. Make request to server(Ajax request) to get a random token(with one time validation mechanism and expire it), You can send the token in the query string and validate it on server if it's same issued token. Identify if the requested page have valid token(popup) otherwise deny the request or show error message. Think of how captcha works, you just need to do it programmatically.
Though it's also not the best solution as token information can be sniffed through network traffic tracker tools like fiddler but it's will work to prevent manual requests.
Is it possible to add an "active login" (Firefox terminology for HTTP credentials) to a browser by using JavaScript? The JavaScript would simply give username and password to the browser. If it is possible: How?
The goal is to get rid of the popup a browser shows when it asks for HTTP credentials. It only shows the popup if it does not already know the credentials.
To do this, I'd like to show a HTML login form, let the user enter the credentials in it, and on submit pass them to the browser by executing some JS and then redirecting to the protected content.
You may try redirecting to a URL containing the username and password:
http://user:password#host/path?query
Note that due to various security restrictions, this may not always work, or generate security alerts.
Say, I have a simple form on my website having three fields : name, password and email.
I have to get these information from the users, and keep in my database.
Then redirect to another website and send all these information using post.
I also have to know whether the user was successfully redirected to that site(HTTP STATUS 200).
Here's how I'm doing it:
For Point 1, I'm simply submitting the form.
After the data has been successfully saved in my database, I'm rendering the following form with hidden fields. This gets submitted and user gets redirected to anotherwebsite.com
<form id="form_id" action="https://www.anotherwebsite.com/form" method="POST">
<input type ="hidden" name ="name" value ="$name">
<input type ="hidden" name ="password" value ="$password">
<input type ="hidden" name ="email" value ="$email">
</form>
<script> document.getElementById('form_id').submit(); </script>
Problems:
I don't think my strategy to achieve point 1 and 2 is correct. I need a better solution. Submitting the form, then rendering a page with hidden fields and submitting it again to redirect to another site just doesn't feel right.
I have no clue to achieve the 3rd point.
Based on your question you might try this approach:
create a form with name, password, email fields in a file ( HTML ).
Submit the form to server.
On the server side get the data (including the form attribute in a variable) and save it to database.
then redirect to the given website ( using the variable you've stored in step 3 ).
You can easily know the status ( 202 or any error) using any of server side scripting language.
If you are sending the user to another website, the only way to know that the user was successfully redirected is for that website to notify you in some manner. Once the user leaves your page (and that's what a redirect is - it tells the browser "leave this URI and go to this URI instead"), the scripts on that page stop running, so they can't collect any further information.
If you just need to know that the information was submitted successfully, your script could POST the data in the background, wait for a 200 response, then redirect after the information has been submitted. But that may not meet your requirements, since you still won't know if the redirect succeeded.
Another possibility which does allow you to know whether the page on the other site loaded correctly would be to open it in a new browser window/tab instead of redirecting. This is the only way to keep your page active (and, thus, your scripts able to run) while loading another page. However, it introduces other issues, like what to do with the original page. (Leave it open in the background (likely to confuse the user) or close itself after seeing that the new URI has loaded (could cause undesirable visual artifacts as one window/tab opens and then the original one closes; destroys browser history)?)
If at all possible, having the final destination site notify you when the transaction completes is almost certainly the best way to go.
To achieve point 3 you need to use cookies if you are actually trying to implement a login-cum-membersarea system. Othewise, you simple need a redirect inside a condition statement.
my $cgi = CGI->new;
if (condition) { print $cgi->redirect('https://www.examplesite.com/file.html') }
for a general way of doing point 1-2, you can look at the tutorial here:
http://practicalperl5.blogspot.com/
I have a username and password stored in a db with 2 way encryption. I would like to use these to log into a site with a JS form like this:
var form = document.createElement("form");
form.setAttribute("method", "post");
form.setAttribute("action", "http://www.someloginscript.com/");
var f = document.createElement("input");
f.setAttribute("type", "text");
f.setAttribute("name", "username");
f.setAttribute("value", myUser);
var f1 = document.createElement("input");
f1.setAttribute("type", "text");
f1.setAttribute("name", "password");
f1.setAttribute("value", myPass);
form.appendChild(field);
form.appendChild(f1);
document.body.appendChild(form);
form.submit();
I would like to submit the form with the password, however to do this I need to decrypt it first. If I decrypt it then the password is visible through the 'Inspect Element' functions. I obviously don't want this.
I have stumbled upon a site called www.clipperz.com which does exactly what I want but I am not sure how. Do I need to implement their open source encryption library from http://sourceforge.net/projects/clipperz/ ? Or is it all smoke and mirrors that makes it appear more secure?
thanks!
edit: I now know that there is no secure way of doing this. Is using curl a more secure way of submitting this form? This way I can keep all the handling of passwords server side?
You haven't specified it exactly, but it sounds like you're trying to use Javascript on one site to automate a login process into another site? Is that correct? It also sounds like you want to use a general login for all users, which you need to prevent the users from seeing.
I don't think this will be workable in the way you're trying to do it. The problem is that the user on the browser has complete access to the Javascript code and all the data it uses, via tools like Firebug. Using these tools, he can even go as far as modifying the code after the page has loaded.
In short, there is no way of letting Javascript handle the data without giving the user the ability to see it.
I would suggest a better approach might be something as follows:
Site 1 sends a message to Site 2, informing it that it wants to log in a user. It tells it the users IP address, the login details it wants to use and other relevant details.
Site 2 responds to Site 1 with a token code which Site 1 then sends to the user's browser.
The Javascript code on the user's browser then posts the token to Site 2 instead of a login name and password.
Site 2 recognises it as the token it just gave to Site 1, and that it has come from the IP address it was told about, and logs the user in as if it had received a normal set of login details.
This process obviously requires you to write code on both Site 1 and Site 2, so you have to have full access to both of them. If Site 2 is a third party system, then you may have to come up with something else.
Whatever information you end up sending to the third-party site, will have to be made available to the user's browser at some point - and at that point they'll be able to inspect it and get the information out.
Alternatively, they could look at the HTTP requests being made from their machine.
The point is, information on the user's machine can't be hidden from the user if it needs to be in a decrypted state on their machine at any point.