Our reliance on technology has increased over the years, but with this huge technological boom, I think security has been left behind, trying to catch up with each new innovation. To me, it's most obvious when it comes to software development.
Think about the startup environment. Small teams with budgetary constraints working to launch a functioning product on the web in the shortest time possible. And what inevitably gets pushed to the background? Security!
In this article, I want to explore the five most common ways a hacker can manipulate a web application to steal money or data from you.
1. Phishing
First up we got phishing (pronounced fishing). As an internet user, you've probably already experienced this.
A hacker will try to imitate trusted parties like big tech companies (Microsoft), your bank, or even your loved ones, in the attempt to access your online credentials. They'll play with your emotions and try to cultivate a sense of urgency. Sometimes they'll even call you up!
A common way of phishing is via email. The attacker will spoof the email address of a company you trust or mimick it very closely. The only remedy for this would be to verify every single important email you get but this is not an easy thing to do. Keep a watchful eye and don't just click any link in any email.
Instead, go through the verified application to ensure what was mentioned in the email is correct. And if something does feel odd, double-check the URL and the email address. You'll usually see that it has some letters or numbers that differ from authentic users and URLs.
2. CSRF
CSRF or Cross-Site Request Forgery can be very dangerous. What a hacker can do with CSRF really depends on what feature they're exploiting.
An attacker will copy a website you trust such as your bank's website... but every transfer you make goes straight into the attacker's bank account. As the name suggests, this vulnerability occurs from one domain (such as one that the attacker controls). This allows the attacker to emulate a set of websites which they use for phishing.
To prevent this, your bank can generate a random number bound to a session variable which is printed in a hidden field and sent along to the server. The server should check if the CSRF token is correct for every form that is submitted which requires the user to be authenticated.
If you want to check for this you have to be very diligent and know how to read a little code. You need to check any form with important transactions and monitor for a CSRF token. This can be in the form of a parameter in the body or the URL but it might also be done using a header. A CSRF token should be set and checked.
3. XSS
This vulnerability occurs when a malicious script has been hidden deep inside a website, such as a simple <script src=http://hackxpert.com/test.js></script>. It might seem hidden but before you know it, your account has been hacked due to the contents of the test.js file which was hosted on the application's own servers.
With an XSS hack, an attacker can run off with your credit card details and start placing some expensive orders. The scariest part is it's easy to hide.
When we talk about reflected XSS we know two basic types being reflected and stored and we also know two sources being source-based XSS and DOM XSS. We will mostly talk about source-based XSS here as it takes a lot of time to explain the Document Object Model.
Source-based XSS is what most people are familiar with and they should have at least seen the following attack vector: <script>alert()</script>
This is great — if you like getting banned/filtered. Besides that fact, this is how hackers sometimes go through the application several times to test for XSS while they test every single parameter.
Reflected XSS means our values are not saved in the database, so if we want to attack someone, we have to send them a link. This is usually not a great thing and it lowers the severity but don't be fooled, clicking on the wrong link is easy to do. The scammers are trying to separate you from your hard-earned cash with some swift manipulation. They can be very sly and hide these types of XSS links.
Stored XSS, on the other hand, is a lot more severe, all a visitor has to do is stumble upon the attack vector and they might lose their money and accounts without even realizing it. The stored XSS attacks are often hidden and are trying to steal your session tokens or valuable information from the page.
4. Insecure Direct Object References
Insecure Direct Object References (IDORs) are easy to exploit and can be easy for a hacker to find. They are devastating the ways you might expect: access to your accounts, credit card information, and digital wallet.
IDORs occur when there are resources that are supposed to be hidden (For example, your address) and only accessible to certain users (the website admin). Sometimes developers might forget to implement proper Authorization controls so hackers will test every single object by changing the ID of the object or by creating two accounts and using the session headers to automate their search.
Hackers can gain personal information and possibly even get access to the function that changes the email addresses of accounts which would lead to the attackers being able to request a password reset after changing the email of an account to their own. If this is a banking application with weaker security you can imagine what the hacker has access to. Most IDORs are well hidden.
You'll usually find what I call second-order IDORs. You get a system to make a request for you, making a call to the export function which then requests certain products. The attacker might not have access to those products but they could make the export function request them which might be seen as a system call that gets executed without a problem.
5. Broken Access Control (BAC)
Broken Access Control is hard to detect while allowing attackers access to all kinds of functionality they are not supposed to have. Like accessing the information of all users with one simple request. The complexity lays in the fact that there are so many endpoints that are hidden behind functionality that may never be touched while pentesting.
Hackers can abuse BAC because of the tendency for teams to remove front-end buttons to access certain functionality but forget to disable the endpoint. Or maybe testers did not test for BAC with all types of user groups or even custom user groups. All of these are possibilities for flaws to sneak into the software architecture and should be monitored carefully. Sometimes the front-end button is removed but not the endpoint due to budget constraints. Consider the budget you'd need if a malicious actor was able to abuse that functionality.
Broken access control should be tested in multiple ways as even the most basic functions could have regression errors sneak into them. This is why it's always better to include automated testing in your testing strategy as a whole to eliminate the threat of BAC. Preferably this could be tested at the API testing layer or even UI testing layer but even a simple-seeming integration test can make a world of difference over having no testing at all.
Summary
These defects are just a small part of a hacker's toolbox. With so much choice, it’s not hard to see that stumbling across the wrong person could seriously ruin your day.
It’s also important to remember that any resource you access on the internet should be secure. Easily test this by opening the URL in a private window. You should never be able to access your own private data during an incognito session if you are not logged in because that means bad actors can view the same information.
Stay safe out there ✌️
