As described here http://blogs.gartner.com/avivah-litan/2010/04/22/watch-out-transaction-signing-is-being-socially-engineered/
The way the transaction signing that was compromised works is that
once a payment request has been initiated by an online banking user,
the bank asks the user to sign his/her transaction on a dedicated
out-of-band EMV CAP reader with the user’s EMV Chip card inserted. The
user is asked to enter certain codes and values on the reader
confirming the currency amount to be transferred and the account it is
to be transferred to.
Well the crooks knew when the transaction signing was being initiated
and simply put an iframe up on top of the user’s browser that changed
the values to be entered so that the users ended up typing in the
fraudster’s bank account as the destination account rather than the
one they intended.
Something to think about when it comes to transaction signatures –
demonstrating the need to keep the entire process off the PC (in this
case) and on another channel entirely.
Can you explain how it is possible to "put an iframe up on top of the user’s browser" and how to prevent that kind of fraud technically ?
It's not clear from the quote, but it sounds like they are talking about consumer endpoint compromise. The user has picked up a banker trojan so their PC has become an untrusted device which can display misleading information. In this case the trojan operators changed the displayed destination account number so that funds would flow to a different party than the one the user thought they were crediting.
The point is that a complete user interface for making secure decisions must reside on the trusted device. Typing information from the PC to the secure device gives the user a chance to check the information is correct, as does a device with an on-screen display of information being authorised.
But there is a missing piece in that the consumer doesn't usually know that the account number they are typing is genuinely that of the party they mean to credit. Unless they've done many transactions with that party before such that they can remember the account number and spot it when it's wrong (and even then that wouldn't necessarily raise flags).
To correct this, the account ID would have to be something recognisable, something like a domain name whose issuance is controlled, rather than an arbitrary number. That would cause problems for any standalone device where you had to type the information, though, as it would then need a full-size keyboard. You could do it with a display-only device, something like Germany's TAN generators that read information off the screen, or you could do it with a very long account number that decoded to something readable, signed to prevent unauthorised changes.
Once the entire decision takes place on the secure device, including amount to transfer and the user-verifiable destination, the problem of the untrusted intermediary (your PC as a man in the middle) is solved and transaction is safe.
Although that information doesn't include the purpose of the transaction, so you could still imagine an attack where a reseller changed the actual items you were purchasing at a particular store, without changing the cost!
This is a sample of an XSS (Cross-site script) attack.
Say for example, Friendster, which had a lot of XSS "holes" before, particularly in the profile page. I can inject a script in my profile page, and make my page look like a login page.
Once another user looks at my profile, it looks like a Friendster login page! Then the user types his username and password not knowing that it was a fraud page. The entered values would be routed to the my server for storage, while the user gets redirected to the actual page.
In reality, the user was never logged out. The user was made to believe that it was a legit page and was made to reveal the account details.
To prevent this, you should not allow arbitrary HTML as well as scripts to get through your site. There are a lot of entry points for attack, usually input boxes that don't have thorough validation. Event SSL'ed sites are not safe if an injected script exists on the page.
Related
We have a form, if a person fills that form, we are hitting POST API.
When user submits the form, complete INFO of API (request url, headers) is visible, I was thinking if someone starts hitting this POST API through server side code, our tables would be filled with junk values?
How can we avoid this bulk data entering the system through API being directly hit by C# client, POSTMAN or any other server side clients?
That's a really open ended question, but I don't think there's a way to do exactly what you ask (detect with certainty if a request originates from a browser or not), nor should you if it were possible - users may have a legitimate reason to use something other than a browser, or someone might want to integrate your API into a larger process, etc.
You should handle this via authentication - require the user to be authenticated with your API, then if they misbehave you can disable their user accounts (either manually or automatically with some sort of abuse detection).
There are times when authentication is not possible or desirable for a web form. At those times a I have used a key generated on the server that I embed in the form.
The form sends back the key along with the rest of the data and you can then make any decisions you need to make based on the key. Like limiting the rate of submissions, allowing only one submission and then expiring the key, etc...
Use a captcha: a challenge is presented to the user to prove being a human, usually an image that contains some garbled text is shown to the person filling the form and (s)he is required to transcribe the text content of the image in the form. If the captcha solution is wrong or missing that POST request to the API will be discarded.
Many types of challenges are commonly used such as audio/visual/logic/mini-puzzles. You can also customize your challenge in a way that fits best with your form. For example Google provides ReCaptcha, a captcha service with js and server api.
This helps you prevent or mitigate bots, as the captcha is a challenge that is very hard for computers but easy for humans.
Using one-time captcha tokens also prevents the replay attacks you are worried about. Also, checking that the ip that received the challenge and the ip resolving it are same helps mitigate other tricks.
This still leaves room for a determined human to spam your form. So you should also keep track of the number of submissions and throttle them by ip.
I was asked an odd question this morning--We have customers who have a number of PDF reports hosted on our services which are accessed through https (not a direct file link, but accessed by a rest url).
Customers often print these reports on a daily basis.
The request is that these reports automatically print (could be default printer) each morning.
My initial reaction is to laugh, because obviously this is impossible without some user action. But the more I think about this, the more I am inclined to believe there may be ways. For example, if there is some generic "print" user with limited access, and if the browser is left open, and some Javascript on the login screen checks the time of day, it might be possible to retrieve files at a specified time and print. I don't believe I can automatically print--but at least I can open a print dialog.
I know the request to automatically send things to a far away printer from our web services is impossible. Wondering if I can provide the next best thing, and if anyone has a good idea to share here.
Okay, this may sound like a stupid question, but this actually is a real life situation I gotta sort out.
The company I work for is using a rather outdated online shop software (PHP) which is hosted on the companys server. Unfortunately, the source code is encrypted and the CMS does not allow me to add some PHP code either, so I guess I'm stuck with JavaScript on this one.
Let's say we have a huge sale start coming up and people start sharing links via YouTube, Twitter, and so on. Due to the software being made somewhere in the last century, some links still contain session IDs which will definitely be shared by some users. This, however, will result in multiple users placing orders on the same customer account or even worse, overwriting existing customer accounts with new customer data.
I know that this situation is far from ideal and that the software definitely needs and update, but this is not an option at the moment. I also know that I'm not getting a 100% solution, so I'm just gonna try to prevent people from accidentally wrecking some customer data.
That being sad, I though about checking the URL for a Session ID and checking the value in document.referrer aswell. If the URL contains a Session ID and the referrer is some other server than ours, I'll just do a quick redirect to the main landing page. Again: This is meant to prevent the average user from accidentally logging into someone elses account due to clicking on a bad link, I'm not trying to prevent proper session hijacking here.
Any ideas on this one? Are there any situations where the referrer might not contain actual values, e. g. the browser not sending referrers at all? Any other ways to sort this out using JavaScript only?
This is the first time I'm building a website with complex login\signup dialog with backend security feats such as email validation with an activation code and ban registration for too many bad login attempts.
I thought I was finished with building the security architecture, but then this came up: How do i block malice users from abusing my new user dialog.
The only solution I could come up with was a cookie handed at the moment of a successful registration with email address that was last used for registration, backend recognizes this cookie on a new registration attempt and prompts the user about the new findings. Maybe even takes a timeout before responding.
But that only makes it intolerable for 12 year olds, it probably wouldn't happen, but someone with even basic skills and good enough reason could brute register thousands of emails with a simple script, I cannot block a user from having as many accounts on my website as he does have email accounts (amirite?)
Any suggestions?
Try integrate a Captcha code or something the user has to do, e.g. a small math. Randomly generate something the user has to do to be able to register. Usually this annoys most kiddies because they would have to change their scripts.
Captcha code is usually something pretty common on public website registration pages...
Also maybe try to register email together with the IP and log IP addresses logged in on that account and prevent new accounts for that IP.
You could record the IP address on registration and if you get a high amount of users from the same IP address you could block it.. saying that spammers can spoof their IP.
I would recommend:
CSRF
Verifying email address.
Record all IPs and block any if necessary.
If all fails CAPTCHA, it won't flush out everything but it kills a lot in my experience.
One possibility would be to generate a random number server side and store it in a session variable which must be returned along with the data, or better still some hashed version of the random number eg. md5. This can be verified by the server.
This means that you only get one attempt per request, kiddies would have to adjusted scripts to suit your site. You could even restrict the frequency at which the numbers can be generated per session.
I would like to know more about the solutions to restrict registering for a website for humans only.
Captcha may seem a proper solution but as it turns out it's not as good as it sounds.
And it's not a problem if a solution is not an option for blind, deaf people etc..
My newest web app uses a process that makes this really easy for the user and secure for me.
User goes to login page, enters their email address and clicks an "I am signing up" checkbox.
The user clicks "register", their email address gets inserted to a temporary SQL table (called signups) and an email with a verification link is sent to the email address.
The user clicks the verification link which takes them to a "create password" page.
After the user creates his password, the email address and password are inserted into the users table–and the entry in the signups table is deleted.
This makes it easy and reliable.
The signups table also includes a random SHA1 hash (for the verification link), a timestamp set for 12 hours after the sign up, and IP Address.
All entries in the signups table that have an expired timestamp get removed at certain parts of the day.
Update
Since writing this answer, I have found that keeping a signup form secure from robots is a never-ending battle.
As time goes on, new technologies and methods are being developed to circumvent security measures. The best thing any dev team can do is periodically be checking the quality of signups, and thinking of ways to make their signup form both more secure and intuitive to use.
Yeah, it is a good bit of work and resources that go into it, but having confidence in your signup form and quality of signups is well worth the expense.
Depending on how targeted your site is, using a honeypot can be quite effective.
In short, you have a field on your form with a common name -- let's say email. Your actual email field has some other random name like larp.
Hide the email field using CSS, and include a text label instructing users to leave that field blank, should they happen to see it.
If any registrations come in with the email field filled in, send a success message back then drop it.
Verifying the e-mail address and allowing only users who have verified their e-mails is the easiest and quickest solution.
You could have users listen to an audio file, and enter the word into a text box. That's what I wanted to do for phpBB3, but alas, they do not allow HTML markup for their verification questions. Alternatively, you can do defense in depth, and have a CAPTCHA be only part of the process.
Instead of captcha (typing in words displayed in an image) I've seen websites that require you to answer a question, usually basic math. I haven't implemented these, but I've seen them several places so it must be something that's a plugin for various CMSes and soforth.
Bottom line is, any system will eventually be circumvented. You can minimize bot-registrations, but I can tell you from experience that there are people out there who will pay other humans (who can pass just about any test) money to sign up for web sites - the pay is generally really poor, but there are always people who will find that acceptable.
So along with whatever solution you use, you'll want to periodically re-evaluate that solution, AND you'll want to have a human being review new registrations (maybe once a day?) to weed out the few 'bots that do get through.