This article aims to give a simplified explanation of what I may find during a penetration test of a web application.
For a bit of context, my name is Abigail and I’m one of the penetration testers here at Amicis Group. I’ve put together a list of commonly found issues, based on the OWASP Top 10: The Open Worldwide Application Security Project that helps define standards across web application testing.
1: Cross Site Scripting (XSS)
Often described as untrusted code running from an untrusted source, this usually targets injection points. It means a malicious actor has inserted some code onto a page, often on a website that is known and trusted by the public, to trick users into clicking or interacting with their software. This can allow the attacker to obtain personal details, credit card information, or even ‘hijack’ user sessions.
2: Session Management
When hosting a web application, you want to know that the users logging in and interacting with it are who they say they are. You don’t want a bad actor impersonating a user after having stolen their password or session token (cookie). Poor authentication or session management can make it easier for a bad actor to impersonate a legitimate user, leading to malicious activity on the site.
3: SQL Injection (SQLi)
This type of attack is a server-side attack, which means it targets the backend of your systems, that supplies your web application with data. Imagine having a friend that remembers absolutely everything. Your passwords, addresses, everyone’s full name… Now you can rely on this friend to provide you with details you may not have to hand! However, if somebody else were able to ask them for your personal details, and they weren’t able to distinguish them from you, it may not be a friend you want to have at all. This is why databases and servers need to be configured very carefully, to only respond to the requests they are intended to and discard all others.
4: Security Misconfiguration
Moving away from analogies for this one, security misconfigurations cover issues such as default credentials, exposed admin panels and unused or redundant services. An attacker probing a target will often try well known default usernames and passwords and scan for common services, because these are publicly documented and reflect how devices and software ship before an administrator configures them. Their first port of call is frequently to test those defaults and services, hoping to gain access using credentials or interfaces you may not realise are still active.
5: Sensitive Data Exposure
This happens when information that is personally identifiable appears in URLs, query parameters, or logs. If the web application were a house, this would be like leaving your purse or passport in plain view of the window.
6: Broken Access Control
As the name suggests, this is when a web application fails to control who can access what. Users, admins, and super users should all have clear permissions. When access controls are not set correctly, users might see sensitive data from others or escalate their own privileges to gain further access.
7: Cross Site Request Forgery (CSRF)
With this one, malicious individuals may take advantage of users logged into a portal or website with the aim of making them perform unwanted actions. To use an example, let’s say you have logged into an online shop where you’re often making purchases. If you opened a new tab, and unknowingly visit an ill-natured page, it might send a request to the other open tab, asking for it to send a very generous gift card to itself.
8: Unvalidated Redirects and Forwards
This one is quite self-explanatory. It involves redirecting users to a malicious site. Always check where links really lead before clicking,
9: Insufficient Logging and Monitoring
Using another analogy here (and I apologise). Let’s go back to the house example. If someone walked up to your front door a few times and tried the handle, maybe even tested a few keys, you would probably want to know about it. The same applies to a web application. If someone is repeatedly trying to guess usernames or passwords, you need to be aware of it, limit the number of login attempts they can make, and set up alerts for any unusual or suspicious activity.
10: Outdated or Vulnerable Components
Using old versions of software or components with known vulnerabilities increases the risk of attack. Keeping systems up to date and regularly patching software closes those gaps.
Until Next Time….
That’s all from me for now. I hope this has helped give a clearer picture of what I look for during a penetration test. If you are unsure about any of these topics, or simply want to hear more analogies from me, feel free to reach out to the team. I’m always up for a cyber natter.
Call us today on 0333 305 5348 or use our Contact Us page to arrange a chat if we can be any help at all!
