I'm trying to create a PHP based game where you have to do all sorts of simple but un-obvious tasks in order to progress to the next level (eg. refresh browser, press keyboard combination, ...) Kinda like the game "this is the only level" (if anyone has ever heard of it)
Now I was thinking: Would it be possible to create a level where they'd have to sign up at a different page in order to progress to the next level?
So say for example they need to sign up to goal.com and if they're signed up they proceed to the next level. The page would need to constantly check if the signup process on the other site is completed. Is this even possbible? And if so, any thoughts on how?
Thanks!
With most sites, given a username and password, you can check if an account exists.
All you have to do is post some data to a url and parse the output for a successful login.
You may have problems with the bigger sites since they have other checks in place to deter scripted logins.
Related
I have a subscription based application that is build using MERN. I've recently submitted the application to be security tested and one of the responses that I received was that the application should not specifically tell the user why their signup application has been rejected for all cases. For example, if they enter a username or email that has already been registered, I shouldn't return an error message that says "Sorry, this username is already registered", as this would allow the user to build a list of users and emails that have registered with our site.
I understand why we need to prevent this, but I don't understand how I can tell the user why there signup submission failed without telling them that it's because that email has already been registered. It seems pointless to reject their signup form without giving them a specific reason, does anyone know what the best thing to do here is?
I have a subscription based application that is build using MERN
The fact you're using MongoDB, Express, React and NodeJS is irrelevant to how your end-users and visitors use your product.
I've recently submitted the application to be security tested...
Watch out - most "security consultants" I've come across that offer to do "analysis" just run some commodity scripts and vulnerability scanners against a website and then lightly touch-up the generated reports to make them look hand-written.
one of the responses that I received was that the application should not specifically tell the user why their signup application has been rejected for all cases
Hnnnng - not in "all" cases, yes - but unfortunately usability and security tend to be opposite ends of a seesaw that you need to carefully balance.
If you're a non-expert or otherwise inexperienced, I'd ask your security-consultant for an exhaustive list of those cases where they consider harmful information-disclosure is possible and then you should run that list by your UX team (and your legal team) to have them weigh-in.
I'll add (if not stress) that the web-application security scene is full of security-theatre and cargo-cult-programming practices, and bad and outdated advice sticks around in peoples' heads for too long (e.g. remember how everyone used to insist on changing your password every ~90 days? not anymore: it turns out that due to human-factors reasons that changing passwords frequently is often less secure).
For example, if they enter a username or email that has already been registered, I shouldn't return an error message that says "Sorry, this username is already registered", as this would allow the user to build a list of users and emails that have registered with our site.
Before considering any specific scenarios, first consider the nature of your web-application and your threat-model and ask yourself if the damage to the end user-experience is justified by the security gains, or even if there's any actual security gained at all.
For example, and using that issue specifically (i.e. not informing users on the registration page if a username and/or e-mail address is already in-use), I'd argue that for a public Internet website with a general-audience that usernames (i.e. login-names, screen-names, etc) are not particularly sensitive, and they're usually mutable, so there is no real end-user harm by disclosing if a username is already taken or not.
...but the existence or details of an e-mail address in your user-accounts database generally should not be disclosed to unauthenticated visitors. However, I don't think this is really possible to hide from visitors: if someone completes your registration form with completely valid data (excepting an already-in-use e-mail address) and the website rejects the registration attempt with a vague or completely useless error message then a novice user is going to be frustrated and give-up (and think your website is just broken), while a malicious user (with even a basic knowledge of how web-applications work) is going to instantly know it's because the e-mail address is in-use because it will work when they submit a different e-mail address - ergo: you haven't actually gained any security benefit while simultaneously losing business because your registration process is made painfully difficult.
However, consider alternative approaches:
One possible alternative approach for this problem specifically is to make it appear that the registration was successful, but to not let the malicious user in until they verify the e-mail address via emailed link (which they won't be able to do if it isn't their address), and if it is just a novice-user who is already registered and didn't realise it then just send them an email reminding them of that fact. This approach might be preferable on a social-media site where it's important to not disclose anything relating to any other users' PII - but this approach probably wouldn't be appropriate for a line-of-business system.
Another alternative approach: don't have your own registration system: just use OIDC and let users authenticate and register via Google, Facebook, Apple, etc. This also saves your users from having to remember another password.
As for the risk of information-harvesting: I appreciate that bots that brute-force large amounts of form-submissions sounds like a good match for never revealing information, a better solution is to just add a CAPTCHA and to rate-limit clients (both by limiting total requests-per-hour as well as adding artificial delays to user registration processing (e.g. humans generally don't care if a registration form POST takes 500ms or 1500ms, but that 1000ms difference will drastically affect bots.
In all my time building web-applications, I've never encountered any serious attempts at information-harvesting via automated registration form or login form submissions: it's always just marketing spam, and adding a CAPTCHA (even without rate-limiting) was all that was needed to put an end to that.
(The "non-serious" attempts at information-harvesting that I have seen were things like non-technical human-users manually "brute-forcing" themselves by typing through their keyboard: they all give-up after a few dozen attempts).
I understand why we need to prevent this, but I don't understand how I can tell the user why there signup submission failed without telling them that it's because that email has already been registered. It seems pointless to reject their signup form without giving them a specific reason, does anyone know what the best thing to do here is?
I'm getting the feeling maybe you got scammed by your security "consultants" making-up overstated risks in their report to you - rather than your web-application actually being at risk of being exploited.
We have security requirement for web application. We need to block the browser instance (includes all tabs) after 3 invalid login attempts. It should be irrespective of user ids.
For example, I open a browser instance and use three different users to login and all fails and the moment i try fourth attempt, it should error on login page saying close the browser instance and try on new instance.
My question is how to identify the browser instance at server side. What are the strategies?
One option is using session id using cookie. But, I would like to make it work even if Users clears cookie in between attempts.
Any other ideas?
Anything you try to do browser side is practically pointless. It won't stop a single malicious user, and will only frustrate your clueless users who forgot their passwords and are trying everything they can think of.
The best way to handle something like this is to "stand on the shoulders of giants" so to speak. How are the big names like Google/Facebook handling this? If your focus is purely on security, and don't really care about user experience, then this won't be your ideal answer. If, however, you have to balance between the two, this is how I'd do it.
Look at what Google does. You get a few attempts per user AND per IP address (you'll need to start recording this if you aren't already). After a few failed attempts, you show them a CAPTCHA. If they keep trying, you are no longer dealing with a bot, and you can adjust accordingly. You have to deal with this by account and IP because malicious users will just change their IP to keep hammering on one account, so you need to be able to handle both cases.
Try to help the user by showing them how (hopefully) easy it is to use the "forgot your password" feature. Maybe if you see enough username attempts from the same IP, you can escalate this to a "lock out" mode. But be careful, malicious users can use many IP addresses, and sometimes regular users all connect through one IP. Also make sure they can't lock out your (admin) account (or everyone in your DB).
Assume I want visitors of my site to be able to fill in a long form. That's not necessary for them to fill it in to use the site, but if they want to send a story to me, they need to fill it in. So, some of them will wish to do it, some won't. The form is quite large so visitor may want to leave it semi-filled to come back later and finish it. To make the process as easy as possible for the visitor, I want him just to click a link "Create a story" that will redirect the visitor to an automatically generated url, like www.mysurveys.com/7Bs3h4vSWEe. Here the visitor works with his form and clicks 'Save' when he wants to save it so that to return back later to finish it. The form data is kept in the database with its generated ID. When the visitor thinks the form is filled properly and is done, he clicks 'Send for review' and then the form goes to me.
The question is: how secure is to use this automatically generated URL as the only credential for the user? I suppose any sniffer could easily get the url visitor uses to fill in the form. How to make a process like this as simple as possible? What are ways to make it a little more safe? I know I can do it using standard user registration pattern but I want to make it simpler.
This ID is a lot like having a session id for the user and in that sense its not a compromise. One difference is that session id's should always expire. If security is a concern then HTTPS should be used to prevent eavesdropping.
This url value should be a Cryptographic Nonce. You should also take brute force into consideration. If someone is guessing a lot of keys that don't exist, prompt them with a captcha.
It's not that secure, BUT sniffing is basically the only attack, AND unless the attacker doesn't care whose URL they get, they would have to target their victim quite specifically.
I wouldn't use this for, for example, financial information, or third-party-confidential information, but for low-risk information it might well be fine.
edit: I've ignored brute force, but much the same applies, and as other answers suggest, there are protections against that, like captcha.
Comcast has changed their login process so it happens in two steps. Instead of two input boxes for username and password, you submit your username first. Then on a second page you enter your password.
https://www.comcast.com/Customers/CustomerCentral.cspx
Due to some recent security
improvements, we now require you to
enter your user name and password in
two separate steps.
What could the security improvement possibly be in this system? If anything it seems less secure since you can confirm the existence of a username independently from it's password.
Any ideas on what they're accomplishing here?
My guess would be that they are targetting specific phishing/keylogging software which is "used to" finding all the login information on the same page. It's making the job of some malicious software a little harder.
If you use the "automatically fill in my forms" feature of many browsers, this will also separate the login information into two separate entries in the browser's data store, again making things just a little harder for any software which might try to exploit this feature.
Not sure if Comcast is doing the same thing, but I know a lot of bank websites I use lately started doing the following:
Prompt you for your username
Look up an image and a string that you specified at your account creation.
Display that image + string along with the password box.
The stated goal is so that, if you as a user notice that the image and string don't match what you picked when you created the account, you get suspicious and don't enter your password.
What is the benefit here? I don't see any either, as an attacker's script can just look up the image and string from the real login page. Maybe it makes dumb people feel more safe.
It is strange, on the password page they require your email and password, not the user name.
The user name is not a secret, as you use it in your mail address probably....
They still allow you to "stay signed in" ...
So Actually, I don't think there is a real security benefit
You can get directly to the 2nd login page if you bookmark it....
Simply so when you login to more secure areas of my account, you need to reenter your password instead of use the remember-me function, so if someone gets on the computer, all they can do is access email from a normal session. Yahoo does this also.
I need to write some code to analyze whether or not a given user on our site is a bot. If it's a bot, we'll take some specific action. Looking at the User Agent is not something that is successful for anything but friendly bots, as you can specify any user agent you want in a bot. I'm after behaviors of unfriendly bots. Various ideas I've had so far are:
If you don't have a browser ID
If you don't have a session ID
Unable to write a cookie
Obviously, there are some cases where a legitimate user will look like a bot, but that's ok. Are there other programmatic ways to detect a bot, or either detect something that looks like a bot?
User agents can be faked. Captchas have been cracked. Valid cookies can be sent back to your server with page requests. Legitimate programs, such as Adobe Acrobat Pro can go in and download your web site in one session. Users can disable JavaScript. Since there is no standard measure of "normal" user behaviour, it cannot be differentiated from a bot.
In other words: it can't be done short of pulling the user into some form of interactive chat and hope they pass the Turing Test, then again, they could be a really good bot too.
Clarify why you want to exclude bots, and how tolerant you are of mis-classification.
That is, do you have to exclude every single bot at the expense of treating real users like bots? Or is it okay if bots crawl your site as long as they don't have a performance impact?
The only way to exclude all bots is to shut down your web site. A malicious user can distribute their bot to enough machines that you would not be able to distinguish their traffic from real users. Tricks like JavaScript and CSS will not stop a determined attacker.
If a "happy medium" is satisfactory, one trick that might be helpful is to hide links with CSS so that they are not visible to users in a browser, but are still in the HTML. Any agent that follows one of these "poison" links is a bot.
A simple test is javascript:
<script type="text/javascript">
document.write('<img src="/not-a-bot.' + 'php" style="display: none;">');
</script>
The not-a-bot.php can add something into the session to flag that the user is not a bot, then return a single pixel gif.
The URL is broken up to disguise it from the bot.
Here's an idea:
Most bots don't download css, javascript and images. They just parse the html.
If you could keep track in a user's session whether or not they download all of the above, e.g. by routing all of the download requests through a script that logs the attempts, then you could quickly identify users that only download the raw html (very few normal users will do this).
You say that it is okay that some users appear as bots, therefore,
Most bots don't run javascript. Use javascript to do an Ajax like call to the server that identifies this IP address as NonBot. Store that for a set period of time to identify future connections from this IP as good clients and to prevent further wasteful javascript calls.
For each session on the server you can determine if the user was at any point clicking or typing too fast. After a given number of repeats, set the "isRobot" flag to true and conserve resources within that session. Normally you don't tell the user that he's been robot-detected, since he'd just start a new session in that case.
Well, this is really for a particular page of the site. We don't want a bot submitting the form b/c it messes up tracking. Honestly, the friendly bots, Google, Yahoo, etc aren't a problem as they don't typically fill out the form to begin with. If we suspected someone of being a bot, we might show them a captcha image or something like that... If they passed, they're not a bot and the form submits...
I've heard things like putting a form in flash, or making the submit javascript, but I'd prefer not to prevent real users from using the site until I suspected they were a bot...
I think your idea with checking the session id will already be quite useful.
Another idea: You could check whether embedded resources are downloaded as well.
A bot which does not load images (e.g. to save time and bandwidth) should be distinguishable from a browser which typically will load images embedded into a page.
Such a check however might not be suited as a real-time check because you would have to analyze some sort of server log which might be time consuming.
Hey, thanks for all the responses. I think that a combination of a few suggestions will work well. Mainly, the hidden form element that times how fast the form was filled out, and possibly the "poison link" idea. I think that it will cover most basis. When you're talking about bots, you're not going to find them all, so there's no point thinking that you will... Silly bots.