This login form keeps changing the names of its fields:
What does that accomplish? What kind of attack does it protect against?
3
-
Pre-scripted login bots?– Yu ZhangCommented Jun 13, 2017 at 20:58
-
2This could be a weird attempt at CSRF protection or they really don't want users to prefill their credentials.– ArminiusCommented Jun 13, 2017 at 21:43
-
2it doesn't protect against any realistic threat that can't be protected with simpler/more mainstream methods.– dandavisCommented Jun 14, 2017 at 16:07
Add a comment
|
2 Answers
Your example is a banking app. Many banks are facing trouble with "scraping" tools which collect information from the bank. Basically, the banks are so far behind on APIs for accessing our information that customers are choosing to give out their usernames and passwords to third party sites which then go scrape their financials and present them in a usable format (such as a CSV file).
Several banks have made the decision that this is a problem, and rather than build the API's, they're just trying to make it harder for scrapers to do their job. Dynamic fields like this are one tool they can leverage. Others have some token encoded into javascript which must be decoded and passed along. The idea is that if they can make it difficult enough for a 3d party to scrape your data, you'll stop giving out your password to make up for their failure to provide the services their customers are asking for.
answered Jul 15, 2017 at 0:25
-
I never heard of something like "Give your bank credentials and I'll scrap it for you". Do you have some of example of such an antrocious security wise service?– Mr. ECommented Jul 15, 2017 at 4:56
-
3@Mr.E Mint.com is an example. Here's an article about Wells Fargo's efforts to break their business model. (of course, the API they intend to replace it with is a) unfinished and b)Intended for business customers only) Commented Jul 15, 2017 at 5:20
-
@Mr.E polipay.co.nz does the same, but instead of just reading, it (by design and non-malicious intent) makes transfers. It not only asks for UserName and Password, but also your 2FA. Lets just say I would never use it. Commented Aug 14, 2017 at 0:56
It appears to be an anti-automation solution. Only whoever originally designed the requirements for this could tell you what exactly they were trying to accomplish, but here are a couple of guesses:
CAPTCHA - Trying to prevent automated form submission by bots.
Anti-CSRF - Trying to prevent Cross-Site Request Forgery
- Prevent browsers from caching login credentials - This solution could target browsers which pre-date the autocomplete="false" attribute.
- Prevent automated security scanners from finding vulnerabilities -
Many security tools, such as fuzzers, will automatically attempt to
submit forms. Changing the field names means these tools need to be re-calibrated.
The this solution would only be 100% effective as an anti-caching mechanism, and maybe as an anti-csrf solution, depending on the specific implementation. It's also overkill for both of those problems. All of the other items I listed could be circumvented, although it would slow down a potential attacker.
-
2Note that it this doesn't prevent caching inputs, it only prevents filling them. So it weakens security because it makes the user think the data isn't saved locally, while it actually is. Commented Jun 14, 2017 at 14:58
-
fuzzers and scanners don't usually run JS, so i don't think they would even see any dynamic names...– dandavisCommented Jun 14, 2017 at 16:05
-
@dandavis This is true, they don't typically run JS, but in order to make sure the forms are received correctly on the server, the server must be looking for the dynamically generated form names. Therefore, the names the automated tool submits must match whatever is shown in the markup. It's still possible to get the tool to work, you just have to code around the speed bump. Commented Jun 14, 2017 at 17:47