Mitigating the risks of public IP addresses

You’ve heard of IP Addresses, you might even know what they are, but if you need to get a penetration test for your website or web application, why is your cyber security consultant asking about these as well?

When it comes to penetration testing your web applications, it’s important to include your public IP addresses in the scope and here’s why.

What is a public IP Address?

Web applications don’t exist in isolation. Their data is on a server (or servers) and so they rely on the server’s infrastructure and configuration to function. If that server is compromised, so is the web application, and that means all your data is vulnerable.

An IP Address is a unique series of numbers that identifies a device (in this case, the servers which host your web application) on a network. It is your identifier which allows information to be sent between devices.

Think about it like this: your device or server is like a house, and the public IP address is the address someone can write on a letter so that it can be delivered to your house. Essentially, without IP Addresses, we wouldn’t have the internet we know today because it wouldn’t be possible to send and receive information.

Why include your public IP address in your web application penetration testing scope

If a server using a public IP address isn’t secure, a malicious actor can trace your online activity. They can use malware or other attacks to gain access to your server and all the data it holds. Here are some of the vulnerabilities we’ve come across in penetration tests:

• buffer overflow exploits
• default credentials
• operating system vulnerabilities
• world accessible databases and mail services - accessible/usable by anyone online
• SSH vulnerabilities – publicly reachable and insecure management interfaces
• Publicly exposed server management interfaces

Overall, a weakness in the configuration of your server which is using a public IP address could lead to data breaches, malware distribution, data manipulation, and loss of business and customer trust.

What if your web app isn’t hosted on your own server?

Sometimes servers don’t belong to the organisations that own or manage a web application; they may be hosting it with a third-party, meaning that they have to get permission from the owners of the server for a penetration test. If permission is denied there is often a process where the third party can show you that the server is secure, and you can be reassured that your data is safe.

One of the most common attack vectors which will be exploited by a threat actor is cyber security weaknesses within third parties and the supply chain. Here are some ways you can mitigate those risks when penetration testing is not available:

• Always use a trusted hosting provider with a good track record in being cyber secure and a Web Application Firewall (WAF), as this will protect your web application from common web attacks.
• Adopt Secure Code Practices in your development team when building and maintaining web applications, including input validation, output encoding, and secure authentication. Properly developed code can mitigate many common vulnerabilities.
• Ensure you download and install the latest updates and patches, which will keep the web application, its dependencies, and the server software up to date with the latest security measures.
• Implement security headers and content security policies to mitigate certain types of attacks and improve browser security.
• Use strong passwords and two/multifactor authentication (MFA) to protect user accounts and sensitive data.
• Use secure communication protocols like HTTPS to encrypt data in transit. If the application stores sensitive data, ensure it's encrypted at rest. Many hosting providers offer SSL/TLS certificates and encryption options.
• Monitor your web application for anomalies and employ continuous monitoring solutions to detect and respond to suspicious activities and potential breaches.
• Establish data backups and disaster recovery plans to prevent loss of data if you are attacked.
• Secure APIs and third-party integrations if the web application relies on APIs or third-party services.

If you have any questions about Web Application Penetration Testing and/or public IP address, or you would like to learn more about our other Penetration Testing services, please get in touch with us.