How can you reduce risk when implementing agile development in your SDLC?
“Where’s my 500 Euros?”
“Stop sending me spam!”
We noticed very quickly that something was wrong when we started getting messages complaining about emails we were supposedly sending out. We would never send out phishing emails like that… right? Luckily, the answer was in the emails themselves.
On the test IO website, we have a page to register to become a tester and apply to join our crowd of verified software testers. On this page, we have a form that asks for a name and an email address. When you register, we send out an email confirming the email address before we activate the account.
Unfortunately, an enterprising scammer in Russia discovered that this form was a great target for a bot and cross-site email phishing. Once an hour, the bot filled out the “become a tester form.” In the name field, it put an entire message about winning 500 Euros, including a phishing link. In the email field, it put the email address the scammer wanted to target.
That’s how our legitimate tester account verification email ended up being repurposed. When we sent the email to what we thought was a new tester, that person got an email with the scammer’s message plus a link to click.
The length and content of the name field aren’t aspects we’d usually think to test in our automated test suites (and there are a lot of assumptions about names that need to be checked). A creative human tester would have found this critical, relevant issue, and helped improve our security.
In case you’re wondering, we’ve fixed the loophole. It’s no longer to paste extremely long text strings in the name field, nor to include URLs.
Even routine updates and setting standard pages and forms (like for registration) need to be checked for security issues and tested for functionality, usability, and regressions. If it’s a completely new feature or section of your website, have exploratory testers run the new code through its paces. You never know what edge case or vulnerability might have been left exposed.
While this particular issue is now in our automated tests, it’s not something our product managers or our developers would have thought to check for in advance. That’s part of why our mission is to help companies build better software and to build software better. Nothing is ever bug-free or perfect, but by testing and iterating, it keeps getting better.