I’ll let you in on a little secret. Most hacks are boring. They aren’t the crazy, complicated “Ocean’s Eleven” style plan within a plan hacks you might see on TV or in the movies. To most people, actually hacking a website would be pretty boring. There are pieces of software you can grab off the Internet, point at a website, and data pops out. Those who take the time to learn basic techniques of infiltrating a website realize that most of the time is spent researching the target.
Some hacks are crazy difficult and complicated, certainly. And these get the big news coverage. These hacks take tons of time and energy to figure out and are usually done in a university laboratory. The vast majority of attackers are looking for easy scores. They want to get in and get out as quickly as possible. Vulnerabilities like HeartBleed or Meltdown/Spectre aren’t those kinds of vulnerabilities.
Web applications get the brunt of attacks because every website is by definition exposed to the public. Many common mistakes, which are well known and have solutions, still crop up and cause big issues.
So here are five of those mistakes and how to get it right so you’re not the next hacking headline.
No input validation
The OWASP Top 10 lists Injection as the number one web application security risk. Injection occurs when input from a user is interpreted as code and executed by your application. SQL injection is a common form of injection. OS injection is also dangerous.
A root cause of vulnerabilities like injection is no input validation. Attackers will check all of your inputs to see if they can put weird stuff in there. Then, they’ll try to create an error. Once an error condition is met, the system usually barfs up more than enough information to allow further attack.
How do you fix this mistake? Validate. Validate. Validate. Understand what you need from each input and check to make sure what you want is what you get. A phone number should be 10 digits, no letters. Your zip code only allows 10 alphanumeric characters. Putting sensible restrictions on what data is allowed stops attackers in their tracks.
Sanitization is another option. Sanitization works by looking for potentially harmful data within a request and removes it. For example, you could strip out quotation marks, semicolons, or other symbols commonly found in programming languages. It’s a good baseline to have, but be mindful that sanitization is not a silver bullet. There are ways to get around it. So whitelisting (telling the computer what is allowed) is more effective than blacklisting (telling the computer what isn’t allowed).
Authentication is broken
Authentication is a key component of any web application. It’s important to know who is using your application. Problems occur mainly with poor authentication mechanisms, which allow attackers to impersonate real users.
A basic authentication workflow includes a user navigating to the site and getting an anonymous session. When a person logs into the site, a new session token should be generated for that user. The session token is given to the user in the form of a cookie. This cookie is passed in with every request so the server knows who it’s talking to. Protecting this session id is key to having secure authentication.
Look for ways that your session tokens could be exposed.
- Don’t place session ids in URLs.
- Make sure your session cookies are marked with the Secure and HTTP Only flags. This ensures that the cookies will only be sent over an encrypted channel and will not be accessible via JavaScript.
- Session ids should be random so attackers can’t guess them
- Sessions should time out so those who leave a computer without signing out, such as in a public library, aren’t compromised.
Don’t leave your front door open. Get authentication right.
Access Control is weak or nonexistent
Sometimes authentication and authorization are used interchangeably. This is wrong. Authentication is identifying a user and verifying that he is who he says he is. Authorization refers to what a user is allowed to do once authenticated.
You may authenticate someone at your house as a friend and let them through your front door. However, this doesn’t mean that they instantly get access to your bedroom. Similarly, once a user is authenticated and is “inside” your application, you need to know and control what they have access to.
Role-based Access Control (RBAC) is a very effective way of controlling what your users can do. Especially with internal systems, RBAC allows you to define roles within your organization, such as “Accounts Receivable” or “Shipping Approver”. These roles are given access to the parts of the system your employees need to do their job and no more. This is called the principle of least privilege.
Systems with external customers also need access control. In this realm, data is the asset that needs to be controlled. Users should see their own data and no one else’s. For example, leaving an identifier in the URL that corresponds to a database key may encourage attackers to randomly guess ids to see if they get one right. If they do, they may see someone else’s information. Not paying attention to details like this is especially dangerous in the healthcare industry. You don’t want patient data getting into the wrong hands, as the consequences could be serious.
Make sure you know who is using your system and what they should and should not have access to.
Data is exposed when it shouldn't be
Sensitive data exposure is a big problem in information security as exposed records are a major threat to the victims and your company.
When using tools like Amazon S3, never make a bucket publicly available. This is not the default for S3 buckets, so a person has to consciously make the effort to expose an S3 bucket publicly. Take the time to set up IAM policies correctly for S3 buckets, only allowing services that actually require access to the data to access it.
Another subtle way data can be exposed is through the user interface. Social security numbers that are unmasked or sensitive information in “hidden” HTML fields could lead to data exposure. And don’t forget about internal applications. Not every employee needs to see every piece of data the organization owns. Make sure users only see the data they are entitled to see.
Data is your most precious asset and is usually the target of attackers. Treat it accordingly.
You’re using vulnerable third-party tools
The Equifax breach occurred because of an unpatched open-source framework, Apache Struts. Attackers used a publicly known vulnerability to get into the Equifax network and gain access to all the data they wanted.
You need to understand what components your application is using and dependent upon. Any vulnerabilities in the software you use but didn’t write yourself could become a vulnerability in your application. If left unchecked, these components could lead to a major breach.
Third-party tools and partners could also lead to data breaches. Some of the major S3 breaches that have happened recently are the result of third-party company employees creating AWS accounts with the company’s data stored in S3 buckets. If your systems integrate with third-party systems, make sure the other company’s security policies are sound. Make it a part of the contract that security processes must match yours if they want your money.
For open source components, keep an updated inventory with the names of open source libraries you’re using and their versions. Have a plan for patch management so vulnerabilities within the libraries don’t cause vulnerabilities within your code.
Simple mistakes lead to major problems
I call these mistakes simple because they are well-known and have solutions. Software developers need to understand these vulnerabilities and how to fix them in the languages they use.
- Validate your input
- Know who’s using your application
- Know what that user is supposed to see
- Don’t leave sensitive data where anyone can see it
- Keep track of third-party dependencies and keep them patched
Developers are under the gun to get features delivered. But they also need to know the basics of good security and secure coding practices. This is best done by giving developers access to on-demand training. When security issues pop up, just-in-time review of the best practices will prevent these simple mistakes from creeping into your software. If you need help to deliver such a training solution to your developers, please get in touch. We’d be glad to help you.
Spy movie hacks are Hollywood, not real life. In reality, many basic software problems that have been around for years are the biggest causes of security catastrophes. Don’t let that happen to you. Pay attention to these basics, and you’ll not have to worry about being the next headline.
