I have created 2 extensions for websites that i do not own and they do not have an api.
when you open the extension, there will be a login screen, but when you close it, you'll be logged out, i want to either save the cookies so when you reopen the extension you'll be logged in or to save the password like lastpass and create an option page, but:
1- I do not want to host the database on my vps, coz i don't want to pay to maintain the extension if i have many users, and i don't want to keep protecting my database from hackers till death :)
2- I do not want to host it on any paid service
unfortunately, lastpass doesn't have an api, so i'm thinking of storing the username and password on the user's pc, and i do not care if he got hacked because it is his responsibility to keep his pc secured and not mine :) any idea or tutorial on how to do it?
and by the way the websites are created using .net framework
You can store information between browser restarts in localStorage.
Related
Apart from all the other typical security best practices I'm wondering about this, since I lately read some articles talking about how browser extensions can spy anything their user does. So that we shouldn't trust them.
Therefore in order to give users and additional layer of protection should I process all users credential and sensitive info inside an iframe inside my webpages?
Can content inside a sandboxed iframe be read/spied by browser
extensions?
Yes
Could I use iframe to secure user credentials?
Quick answer, no.
When a user installs a chrome extension the extension can do basically anything in the website to access the user credentials. The extension has also access to the iframes that the page generates.
My proposed solutions to overcome this two issues and keep the website feel "secure" are the following:
If the end goal is to secure the content that your user will put in the website, and by no mean you want to let the user put content if there are other kind of extensions running in the page, what you can put is some kind of pop up in the page blocking the access to the user until he is accessing the website without extensions.
Another solution you could propose to the user is to go incognito mode, as there are many options to disallow extensions in incognito without having to force him to uninstall all of the extensions that he has on his browser. This could also make less users leave your page, as if you force him to uninstall of the extensions on his browser it might make him leave your page if it's not a clear enough reason for him.
If you do know which are the extensions that shouldn't be blocked or prevented because they are harmful or known to have some kind of shady behaviour, what you can do is checkout if the user has them installed with this solution Checking if user has a certain extension installed and then print a message to him saying he can't continue until he uninstalls those extensions.
My website is working with some ISP while it is not working with others. Also not working from other countries.
The app is hosted at our company. Developed using sharepoint asp.net.
The app works at my home.
But if I visit the website at my brother's home who is registered to different ISP, the website opens and a login dialog appears. When entering correct username and password then submit , textboxs cleared and dialog come again.
The problem is happening with many visitors.
I just want to know what would be the problem! Does anyone faced such problem before?
I checked all IIS restrictions. There is no restrictions made.
I created a new app using sharepoint with login page and it works great.
somebody said that users with public ip can access the site while others with dhcp cannot. Can somebody explain that !
Some ISPs have transparent proxies in use. And some of them are accidentally (or even intentionally) broken and cache more, than they should. You can check whether that's the problem:
Set up your server to also allow https and then use that. You should move to https for privacy reasons anyways, so just do it now ;)
This way, the proxy can't do anything but to pass the data between client and server unmodified.
If that is not an option: Use tcpdump/wireshark/other-sniffer on both - client and server - at the same time and compare the logs. Did the second access even make it to the server?
Do you have a laptop/tablet/smartphone with which you can access the web server? Try moving that laptop from one location to the other and check, whether it works with that one laptop using one ISP and fails with the same laptop on the other ISP.
This should be a comment, but I do not have enough to post it as such.
Are sure that it is not a browser issue?
Is the login dialog from SharePoint, your app or the browser itself?
If it is from your app, can you debug it or write the log-in attempts in a log?
I am writing a chrome extension, and I want to find out if the built-in password manager has saved the password of a specific website.
I don't want to know the password, just to find out if there is one for this website.
do you have any ideas how can I do this?
There is no API to interact with the password manager.
There may be very hacky ways of inspecting the loaded login form, but I don't think you're looking for those.
I am working on a website related to physically/psychologically abused person.
There is an emergency exit button available all time so the user can click on it before the "aggressive" person enter the room where the computer is located.
When the user click on the emergency button, the user is automatically redirected to Google with a query like "cooking apple pie" (this is an example).
Also, we would like to hide our website from the browser history in case the aggressive person check the history of the abused person. I think this cannot be done technically.
At least, can we generate fake browsing history to justify to the aggressive person the time that the user was on our website?
I tried multiple things to simulate a "browsing" like using an iframe or an ajax query to another website but none populate the browser history.
Is this can be done?
Thank you for your input!
I think you may be focusing too much on the browser and computer that you do not control and not enough on the content and the server that you do control. How about taking a different approach? Why not generate the pages for the user on the fly? The links are only good once. If you click on the home button (your escape key) and the aggressive person looks in the history the attempt to access them a second time could be made to display the weather or lottery results or something innocuous, Focus on what you have control over.
Useful Technical Details
Removing/Preventing Back Button Click History
You can allow the user to browse throughout a webpage without building up a history trail on the back button by having them click exclusively on javascript: links. This would still not remove any of the visited websites from their full browser history, so it's not a full solution.
Here's an example HTML JavaScript link:
CLICK HERE TO ESCAPE!
If this is acceptable, you could build an inoffensive homepage from which the user could access the site that would use JavaScript to send them to the real website. Every link on that new website would have to be a javascript link. Disadvantages of this would be that they would no longer be able to use the back button to navigate and that JavaScript is 100% required for the site to function.
Sanitized History
Make sure you have inoffensive titles and icons for any pages in the site so if the user does not delete their browser history they will not grab the attention of the third party.
Preventing Access to Protected Content
One option you have is to disguise your website as something else by having the user log in before they are allowed to access any of the content. You could save their session/login data in such a way that it is cleared if they hit an escape button it is erased or reset. As part of the login page, you could give users an alternate password to type in that would redirect them to fake content if their abuser becomes suspicious enough to demand they log in.
The session/login information should never save between browser sessions and always have a short expiration period, to further reduce the chances of the abuser gaining access to the website.
Disguising the Site
Considerations
If you choose to disguise the site either on the homepage or behind a "fake" login, be very careful to choose something that makes sense and would not arouse suspicion or interest. You don't want the fake page to be some sort of game or anything that might pique the third party's interest.
You also don't want it to look so boring or mundane that the original user would be hard-pressed to explain their possibly frequent visits. It shouldn't be anything so specific that the third party would think twice about the original user visiting it though. For example, it might be suspicious if someone who does not enjoy the great outdoors were to be visiting a page on mountain biking.
It also can't do something like just redirect them to Google without explaining the fact that they had to log in to access it.
General Advice
Private Browsing
Multiple sources have suggested either educating your target audience in how to use IE's InPrivate Browsing mode, Firefox's Private Browsing mode, or Chrome's Incognito mode.
There unfortunately does not appear to be a way to prevent the browser from keeping the current page in its browsing history through JavaScript. It's possible there might be some sort of plug-in or third-party control which would enable this, but it's probably just easier to get your users to use a private browsing mode.
Clearing History
Clearing a user's web history would not be possible since browsers restrict websites from accessing or altering data on the user's computer directly. Since the user's browser history is part of this data it would be a security issue if any website could clear the history.
You should provide instructions to your users for pruning or clearing their browser history, whether on the website itself before they enter, or through whatever resource you showed them how to access your website.
Generating a Fake History
If you need to generate a fake list of visited websites, you can always create new tabs/windows for the users (or possibly iframes) at timed intervals with JavaScript, but the user would have to disable their popup blocker for this to take effect.
Further Reading
Here is a helpful article on creating a useful Quick Disguised Exit From A Website. This forum thread that I found it on also had some useful information, but it's likely you've already seen it.
At least, can we generate fake browsing history to justify to the aggressive person the time that the user was on our website?
Have you cosidered turning it around?
What if technically all your pages and its content are about something else. So it is the content you want to hide that's loaded in a special way, making it easier for you to avoid having it in the browser history.
So then it becomes about knowing when to load/show the special content.
Above said, it's very important what #Frédéric Hamidi said:
Just keep in mind that if the "aggressive" person has control over that computer or the network, nothing can really prevent him/her from installing loggers on the machine or analyzing network traffic.
IE's InPrivate Browsing mode, Firefox's Private Browsing mode, and Chrome's Incognito mode
I would recommend this to prevent the abuser from finding the secret site in the browsing history.
Also, opening a social networking site and letting the browsing history collect that would be an excellent and believable excuse for the time spent on the computer.
We have a client who uses a website we have created. The requires the standard username/password combination to access site contents.
In IE, FF and Chrome the browser offers to remember the login credentials, but our client is using some built in Lotus Notes browser and it doesn't seem to offer this service. Since the Lotus Notes browser seems to be a wrapper on IE, it might be sufficient to clear the login-cache in the browser.
Our client is not a superuser in any way and we do not have access to a Lotus Notes system. We don't want to clear the login-cache in the browser if it doesn't help and causing our client to loose any existing login-credentials.
Question 1: Does anyone know if the Lotus Notes browser can remember login credentials?
If yes:
Question 2: Can anyone confirm that clearing the login-cache in the browser force it to offer to remember the login credentials?
I'm using R6.0.4, so this is definitely outdated, but I do not get a prompt to save a password. It's possible a newer version offers that capability, but my guess is IBM is investing very little in making the wrapped IE browser or the Notes-internal browser work much better.
As an alternative, Notes can be set to use Internet Explorer or Firefox as its browser when it launches links. That can be managed in the location document. In v6, that can be edited by clicking the location name in the bottom status bar, and then selecting "Edit Current..." In there you can select what internet browser is being used.
If there's a need to maintain that setting on the user's notes client, then another work around is to create a duplicate of his/her primary location document (usually the Office one), and change it say "Office - Firefox" for example. That location document can have all the same settings except the browser preference. Then when they need to work on the site, they can easily switch locations first.