I'm writing a firefox addon that logs certain user activity and displays some statistics on a webpage.
When the page is opened, the page sends an event to the addon.
The addon adds data to the page and sends an event back, and the page refreshes the statistics.
Now how do I ensure that the extension only puts the (sensitive) data on the right page and not some other malicious one?
Thanks
V
SSL. Unless you're doing something weird, the only route of attack is man in the middle.
The addon will have to authenticate with the server, probably with a username/password provided by the user. The server side needs to control what events, and from what user that it can accept from the client side. Also note that all authentication should be done over SSL to prevent session hijacking.
Related
I am working on the logout part of my website and I am using JWT for authentication and using cookies to send the JWT for client side.
For logging out I am passing some dummy token value with the same token name so that it over rides the previous token. But when I log out of the portal, I am still able to access my dashboard. There is some glitch in the logout functionality. I guess it is due to the browser cache.
I have few questions regarding Express.
Are there any ways to reload the current page using Express and delete the browser cache while doing so?
I need to disable the browser forward option of chrome once the user is logged out, how can I achieve this using express?
How to redirect the user to his dashboard when he tries to hit '/login' or '/signup' route when he is already logged in? I am using the JWT authentication for login
Thanks in advance
Are there any ways to reload the current page using Express and delete the browser cache while doing so?
The server can't, on its own, tell the browser what to do. The browser has to initiate communications and then act on that communications.
You could have the web page in the browser reload its own page using Javascript with window.location.reload(true) at any time. If you want the web page Javascript to be told when to do this by the server, it could either send regular Ajax calls to the server and, based on the response, decide when to reload the page. Or, it could have a webSocket connection to the server and the server could send the web page some data that, when the web page received that data, it would see that it should reload its page.
We could help you better if you told us what the real problem was here. Web pages can use Javascript and/or webSocket connections to dynamically update themselves rather than just reload all the time. That's a more modern design.
I need to disable the browser forward option of chrome once the user is logged out, how can I achieve this using express?
There's a discussion of disabling the forward button here: HTML5 history disabling forward button. You will probably find this is a brute force approach (it involves getting rid of browser history) and there is likely a much better way to solve whatever real problem you're trying to solve. It also sounds like you may also want to manage browser cache expiration too.
How to redirect the user to his dashboard when he tries to hit '/login' or '/signup' route when he is already logged in? I am using the JWT authentication for login
When you detect a request to '/login' or '/signup' in Express from a user who is already logged in, you just respond with a res.redirect("/dashboard") from your server. FYI, there are lots of questions about whether this is the proper user experience. A user going to '/login' or '/signup' when they are already signed in could have any one of these use cases:
They don't realize they are already signed in or they don't know if they are signed in as the desired user.
They want to sign in as a different user.
They want to create a new account (different from what is currently logged in).
They are trying to figure out how to log out.
You should make sure that blind redirecting (and not taking the user to the page they asked to go to) still makes all these use cases entirely clear. If not, you will just frustrate the user by not taking them where they asked to go.
I have a web site that accomplishes user login via ajax call over https. Obviously the request contains the password. Playing around with Firefox developer tools I noticed that I can inspect any network requests coming from my page including the request body ... and there is my password. I assume the request is being encrypted since its over https but the developer tools still shows it as plain text. Am I missing something? If a user logs in on a public machine and forgets to logout anyone can use developer tools to grab their password. Thanks in advance for any help you can provide.
-Mike
Everything is functioning by design – there's nothing wrong.
The browser's dev tools are intended to allow the user to inspect everything that's happening in the page – without that functionality, they'd be pretty useless. The dev tools' network tab shows HTTP data before it is encrypted.
In the public machine scenario, remember that the dev tools only show network requests that happened after the tools were opened, so an attacker can't just open the dev tools after the user leaves with your page up and see the plaintext auth request.
I can inspect any network requests coming from my page including the request body
No you can't - that's not yet network traffic - that's a HTTP datagram which is then passed through the SSL layer before it gets to the TCP stack.
If a user logs in on a public machine and forgets to logout anyone can use developer tools to grab their password
No, because unless the page developer is doing really stupid things, the browser does not store the information - you could only see it because your browser was configured to intercept the information and store it temporarily. But having said that there are a large number of things which can cause the browser to store authentication tokens - auto complete and password managers for a start (the latter vary greatly in the quality of their implementation, the former has little protection against disclosure). Authentication tokens should never be sent as GET parameters hence should not be visilible from the browser history.
I'm brainstorming a C# project to auto-login to a web portal when a hotkey is pressed. The username and password need to be securely sent to the web portal to login. I have created the hotkey and storage, and retrieval of the credentials, but I'm stuck on how to actually open the default browser and login.
Things I have thought about:
Sending hashed values in the URL (HTTP Get). This is great, because I can just call System.Diagnostics.Process.Start(loginUrl);. But, this creates a LONG URL and run the risk of copy and pasting the URL (I don't want the login URL to be portable or reusable).
Grabbing the COM object and sending into visible forms the creds, then hitting a hidden submit button. All while the current page shows some 'loading' splash. But, this requires grabbing the COM object of an open browser or creating one based on the default browser and hoping that browser compatibility allows me to access the DOM to set the text in the forms and it the submit button. (all hopefully through SSL, although I'm not sure how that will affect things from my end if at all)
I have seen examples on this site using WebRequest and WebResponse. But, do those actually give the commands to the default browser? Or does that make a connection right to the C# program. Becausewhat I really want is to "forward" the credentials to a browser like IE so it can login. Assuming the webpage that I am contacting is HTTPS, then that means I can send unencrypted credentials to the form since they will be secured over the internet? And the end user will not be able to copy the creds since they will be submitted to hidden forms right?
To conclude: I'm looking for a secure way to send credentials to a browser to use to log into a web portal without having to worry too much about browser compatibility.
Thankyou for your time and let me know if I can provide any more information.
My question is simple regarding password security..
As a web application developer using PHP for example, I may design a html form that accepts a username and password and post them to the webserver using the POST method..
My question is:
1- When a user enters a password for this form on a web browser, does this web browser send the password over the network as plaintext and thus insecurely?
2-isn't it possible that the web browser saves all passwords and sends them to the third party that design the web browser?
Thank you in advance
Yes, unless you're using https, which encrypts everything sent between the server and the client.
Sure, but you could use a network sniffer to verify that the browser sends no information to third party servers.
It's sent unencrypted (though possibly obfuscated) if you're using HTTP, or encrypted if you're using HTTPS.
Any mainstream web browser won't do that, no. It would be discovered within seconds of the browser being released. However, it's possible for such a leak to occur by other means, for example:
o A rogue browser plugin
o A rogue proxy on the user's network (if you're using HTTP)
o A keylogger on the user's machine
Is it possible to secure only the Login.aspx page (and the postback) and not the whole site in IIS?
We are looking to do this specifically with a SharePoint site running Forms Based Authentication against our Active Directory.
Links to this will be helpful.
This is what we have done so far:
1. Setup SharePoint to use FBA against AD.
2. Moved Login Page to Secure/Login.aspx
3. Set the appropriate Login url in web.config as https://..../Secure/Login.aspx
This is not working and help is needed here.
However even if this works, how do we get the user back to http from https?
There's not a whole lot of point. If the only thing that's encrypted is the Login.aspx page, that would mean that someone could sniff all the traffic that was not sent through the login page.
Which might prevent people from getting user:pass, but all your other data is exposed.
Besides all the data which is exposed, and the user's operation which can be changed en route, the user's session id (or other authentication data) is sent in the clear. This means that an attacker can steal your cookie (...) and impersonate you to the system, even without getting your password. (If I remember correctly SPSv.3 also supports builtin password changing module...)
So I would say that this is not a Great Idea, unless you dont care about that system very much anyway.... But then, why bother with authentication at all? just make it anonymous?
I agree with AviD and Dan Williams that securing only the login page isn't a great idea because it exposes other data after leaving the password page. However, you can require SSL for only the login.aspx page via the IIS Manger. If you navigate to the login.aspx page in IIS Manager (I believe it's under /_layouts), you can right-click on the individual file and select Properties. From there, go to the File Security tab and click on the Edit... button under Secure communications. There, you can check the Require secure channel (SSL) box, and SSL will be required for that page only.
I'm not positive about getting the user back to http from there, but I believe its default behavior is to send you to the requested page if the login is successful. If not, I would think you could customize where the login page sends you on a successful login.