Protect Your Software with These Nine Security Questions
[Original post here.]
Today, entire businesses are built around a single website. To safeguard this investment, web security issues must be a primary consideration. Written to explore some of the most common vulnerabilities and security holes, let this post serve as a primer to protect your data and your business.
Web Security Issue 1: Is It a Problem, If My API Documentation Is Visible?
Yes. Let’s imagine a business has just published a web application. It is composed of two parts. A front-end using Angular and an API for the back-end.
Exposing your API documentation and application logic puts your solution at risk. With one URL, potential assailants will be able to see all your endpoints, all parameters they require and if they need authentication.
I’m protected if my documentation url is not specified anywhere, right? Attackers who may want to harm your solution don’t need a URL to cause serious damage. Actually, most web applications use standard tools to generate their documentation. All those tools have a default URL to load it that is known to everyone. Every response has extra parameters in the response Head. For a .NET API those parameters will look like:
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
From those, potential attackers know the server OS, the IIS version and the technology used to write the API. From there, they can search for the most common tools used for that technology. This will narrow down your documentation URL to roughly 5.
Web Security Issue 2: Should You Protect Your Endpoint Parameters?
Yes. If potential attackers can easily find your endpoints and expected parameters from your API documentation, they can break your application’s normal working process by sending requests with poorly-formated parameters.
Why Is This Dangerous?
Let’s say your application includes a simple paged gallery. You need to pass the number of results returned as a parameter, but you don’t have any limitations or validations. Attackers can write a simple iteration that will iterate forever by sourcing 10,000 results on each request from your gallery. This would result in increased server load and, likely, a slower application.
Consider this scenario. You are using cloud-based hosting like Amazon, and you have configured it to add more CPU Cores and memory, if site usage is more than average. Amazon will charge you more for that extra processing power per hour. This is problematic if an attacker continues to target your gallery, and you did not add validation for the maximum gallery results.
Web Security Issue 3: Will My Application Be Safer, If I Use Authentication?
Having authentication does not make your application secure. Storing any kind of user information provides incentive for assailants to hack you. Authentication and authorization hijacking can also be used to steal your users’ identities.
Probably the simplest one attackers use is Cookie hijacking. If a user is logged in and an attacker finds a way to steal the cookie, it is then very easy to inject it in their own browser. After reloading the web page, the attacker will have full access to the user’s profile. That attacker can then steal the user’s personal information and sell it to someone else.
Why Is This Dangerous?
Not thinking about your users’ safety is a huge problem. Mainly because each user’s account includes personal information, even if just an email address. Often people have a single password for all accounts. Imagine if someone steals your user passwords, and those passwords are also used for online banking.
Web Security Issue 4: Do Small Web Applications Also Need Protection?
Everything does. Even if you have just a picture gallery and comments as the only user input. Let’s say you don’t validate user input for comments. Attackers can use the cross-site scripting (XSS) vulnerability and save a comment that is actual JavaScript code. If an attacker writes a bunch of comments all of which show a JavaScript alert message and save them, the next time someone opens the page, the JavaScript will execute.
Why Is This Dangerous?
Imagine how your users will feel, if they are inundated with alerts one after the other, when they load a page. Even if developers add validation, it may be too late, because you have already lost most of your users.
Web Security Issue 5: Do I Need to Validate All User Input?
Among the web security issues, this one is critical. Developers must always validate user input both on front-end, and it’s absolutely mandatory on the back-end. Even if the development team forbids script tags in user input, there are other ways a hacker can inject JavaScript in your page.
Let’s say your application allows users to embed an image on the page. Attackers can use cross-site scripting together with cross-domain/cross-origin policy vulnerability to find a way to insert an image element in the HTML. Instead of the source pointing to a picture url, they can put a link to a JavaScript file inside the image source attribute. When the page is loaded, it will not show an image, but it will load the JavaScript file.
Why Is This Dangerous?
Being able to execute JavaScript on a website is actually all an attacker needs to inflict damage on your website. If successful, he/she can manipulate the page HTML. For example, they might insert a form that asks for user credentials and submit them to a private server. Or, maybe they add a false message alerting users that they have won $100, and all they must do is provide select information to collect the winnings. That is the beauty and terrible power of XSS. For the average user, everything looks like it is part of a web site they trust.
Web Security Issue 6: Should I Let the User Upload Any File They Want?
Another of the high impact web security issues is allowing the upload of executables, or batch files. It is a recipe for disaster. If those files are stored on the server, there is a risk of an OS Command Injection. If possible, restrict file uploads to images or pdf files. But, that doesn’t necessarily mean you are protected.
Let’s say you allow the user to upload an image. Assailants may use this to their advantage. Before uploading a photo, he/she may edit the image source and add some script at the end of it. It will still be a valid image. But, if the files are not checked for a code injection just opening or returning the image (in some cases) means the image source will be read and executed. Any injected code inside will be executed as well.
Why Is This Dangerous?
Uploading files is also considered user input. If you allow users to upload executable files, they may write a batch command to format your entire server hard drive. Or with an image and some code injection, I can execute code that will load all your users from the database and delete them.
Web Security Issue 7: Will HTTPS (HTTP over SSL) help?
Adding https will make hacking your application a lot more difficult. But determined assailants can still use a man-in-the-middle attack to sniff out traffic. In a very simple and rough example, let’s say you and a neighbor use the same internet provider. An assailant can connect to the closest internet provider router and start sniffing all internet traffic that comes through. They can filter all traffic that points to a specific website, so when a request is made, all data, authentication and cookies can be seen. How is that possible? For man-in-the-middle attacks, it doesn’t matter if the destination web site uses https. Since all traffic is being routed through the assailant, who can then still route it through the https as the site requires.
Why Is This Dangerous?
While the example above makes https sound a bit toothless, it’s an absolutely necessary practice in the modern world wide web. Not using encryption for storing data and data transfer is a huge security weakness. It would make sniffing traffic very easy and expose your users’ identities and private data.
Web Security Issue 8: What If My Users Never Log Out. Is That Dangerous?
Yes. If you allow users to remain logged in, you must take additional precautions to protect them. Let’s say a user is logged into a website an attacker wanted to target, and at the same time they are browsing another website that is hacked. With cross-site request forgery (CSRF) from the hacked website, the assailant can make requests to the target website on the user’s behalf. It’s not even necessary for the target site to be open in the browser. The target website will think that it’s the user, since he/she is still logged in.
Why Is This Dangerous?
Cross-site request forgery (CSRF) is very dangerous since an attacker can target several websites at the same time. This attack doesn’t apply only to websites to be logged in, to work.
Let’s take this example. Imagine a user hasn’t logged out of his/her favorite payment system. With a few requests, attackers can wire money to other accounts on the user’s behalf, without raising red flags. It’s more difficult for users to prove fraud if the transfer history shows the user him/herself made the transfer.
Web Security Issue 9: Will IP Restriction Help?
Even if a solution is built to allow only a single IP to make requests to the server, other programs called Network Mappers can ping your server IP with every possible IP address in the world. Within 10 minutes, an assailant can cull a list of all IPs allowed by your server.
Why Is This Dangerous?
Many developers think this is all they need for a secure application and still leave their application vulnerable to the attacks above. IP Restriction is definitely a good way to restrict access to your server and help prevent web security issues. But it’s not foolproof. After a potential attacker has a list of IP addresses that your server is open to, he/she can make requests to your server faking the IP address by connecting to a VPN service. From there, he/she can make all the requests desired.
Are We Doomed to Insecurity?
After reading this and analyzing some of the common web security issues, it may seem as if on the internet, nothing is safe. By learning about the types of attacks that attempt to victimize users, development teams can create more secure software.
End users can also protect themselves by remaining alert for the follow red flags:
- When a website asks for your personal information
- Asking for your credit card (even if it says you won money)
- Check if it uses HTTPS (For payments, it’s absolutely mandatory.)
- Clicking on a button (even if the only option is OK) or link, if you are unsure about the intended action
Innovate with us. Click here to access all of our free resources.
Authored by Kaloyan Stoilkov.
