There are no (and probably never will be) completely invulnerable information systems. Any and all applications, web or desktop, can be hacked. Some more easily than others.
Aware of this, it is the obligation of each software house to protect its customers' data in the best possible way. And to do this, you need to know your enemy: how does the hacker act? What loopholes does it look for and use to invade my system? How can I prevent myself?
Let's analyze the top 10 security vulnerabilities in web applications, and discover methods to cover these gaps. Let's go?
What are the main security vulnerabilities in web applications? The main security vulnerabilities in web applications are also the most common, and precisely for this reason, they are the most dangerous.
Before trying more complex methods, an attacker will certainly try to hack your application with simpler strategies. Only after testing the most common vulnerabilities and failing does the hacker switch to a more complex approach – or give up on breaking into your system.
  1. Injection This type of flaw is well known for the SQL Injection technique, where the attacker performs inappropriate queries on the database, using a form or URL.
With this, the hacker can log into your system with administrator privileges, and exploit this access as he wishes.
  1. Broken Authentication This failure occurs when the system does not use reliable authentication and storage methods for user information, with access credentials that facilitate brute force attacks.
One of the most common examples of broken authentication is using very short passwords that facilitate brute force attacks. This is usually the first way a cracker will try to break into your system.
The most immediate solution to this problem is to create a secure password policy, with a minimum number of characters, combinations of letters and numbers, etc.
  1. Sensitive Data Exposure Tools for inspecting elements on a page or web application, such as Chrome DevTools, are among the favorite tools of developers, and also of malicious hackers.
Many APIs do not properly protect the information transmitted through them, which allows attackers to take advantage of the parameters returned by them simply by inspecting the 'network' tab on your system.
In this regard, it is necessary to pay special attention to defining how this information will travel through the interface, and encrypting it properly.
  1. XML External Entities (XXE) This vulnerability is specific to systems that work with the XML language, such as software that issues electronic tax documents.
Attackers can exploit vulnerable XML processors, where they can inject malicious code and send it to an application that will read this XML.
  1. Broken Access Control This failure occurs in applications that have pages and routes with information that only the administrator should have access to, but user control does not work.
In this format, the hacker can authenticate as an administrator, and from there, access, copy and even delete your data.
To prevent broken access control problems, the access profile validation must come from your server and cannot be changed externally.
  1. Security Misconfiguration These are factory default settings, open information in the cloud, incorrectly configured http headers, verbose errors that precisely indicate the reason for the error.
The solution to this problem is very simple: always remember to delete the default files and configurations of the frameworks you use. Some frameworks will remind you of this after installation. Others don't.
  1. Cross-Site Scripting (XSS) Just like SQL Injection, this flaw is very well known on the internet. Through it, attackers are able to insert malicious javascript codes and html tags into the page.
Typically, cross-site scripting requires a certain user behavior, such as accessing a specific link. However, when executed well, this type of fraud is very difficult to identify, especially for lay users.
  1. Insecure Deserialization Fault widely used for remote execution of malicious codes. Even when this security flaw does not result in remote access by the hacker, they can use the loophole to escalate privileges, configuring themselves as an administrator.
  2. Using Components with Known Vulnerabilities Even if your application is developed following a secure standard, the third-party libraries that your application uses may have flaws that are known on the internet. This results in exploits, software ready to be used for an invasion.
Therefore, it is necessary to be aware of possible vulnerabilities in all components, libraries and APIs that you will consume in your software.
  1. Insufficient Logging & Monitoring A system without logs cannot detect that somewhere in its API/System someone is trying to exploit some flaw.
Many developers are resistant to implementing a log module in their system, mainly due to the weight of this data in the database. If this is the problem, set a log self-deletion period that you can support. One month is the minimum!
Another solution is real-time monitoring, which allows you and your team to notice strange behaviors in your system, such as spikes or absurd drops in access.
Therefore, it is important to maintain live information panels for your application, normally on monitors or televisions always connected to this screen, with sound alerts if deemed necessary.
I hope you enjoy my inaugural article and I look forward to contributing in a meaningful way.
Amazing write-up. Lucky to have you here @Azik.
How do you think about overcoming this, if you’re a small under-staffed startup?
Specifically wondering about the benefits of bounties vs internal work vs specialist contractors who work in this area? Or is just something better than burying your head in the sand?
Feels like as you say, quite a large rabbit hole and no perfect security setup for any company, just risk mitigation.
reply
Re: bounties....
For start ups, I would definitely recommend against a public bug bounty program. There are a LOT of bad faith reporters out there who are trying to convince people that their apps are full of critical vulnerabilities, and that can be a lot to weed through. Running a public bug bounty program means you're obligated to respond to every reporter, which can be overwhelming, unless you've hired an employee or a third party triage service like HackerOne to handle that work. Additionally, if your site is still relatively new, it could be more likely to have bugs, and you can find yourself putting bandaids on bandaids. Just paying upfront for a pentest is probably a better use of those resources.
That being said, running an invite-only private program can be somewhat beneficial. You're less likely to get people trying to tell you your exposed google maps API key is a critical finding, and the legitimate reports tend to come in at a more manageable pace.
Re: realistic solutions
Personally, I think trying to find a company or an individual that does consulting for startups is a good way to go, but I don't know of many.
If you're seriously looking for solutions, lmk, I do this kind of thing for a living and I'm actually looking for opportunities at the moment. But I'd be happy to help in whatever way is best for you, so I'd be happy to at least point you in the right direction if I can't help directly. We definitely need more people thinking about this kind of thing.
reply
21 sats \ 1 reply \ @davidw 3 Apr
Great to know frosty. And thanks for the thoughtful answer
reply
Anytime!
reply