How to Minimize Web Security Risks to Avoid Getting Hacked - dummies

How to Minimize Web Security Risks to Avoid Getting Hacked

By Kevin Beaver

Keeping your web applications secure requires ongoing vigilance in your ethical hacking efforts and on the part of your web developers and vendors. Keep up with the latest hacks, testing tools, and techniques and let your developers and vendors know that security needs to be a top priority for your organization.

You can gain direct hands-on experience testing and hacking web applications by using the following resources:

Practice security by obscurity

The following forms of security by obscurity — hiding something from obvious view using trivial methods — can help prevent automated attacks from worms or scripts that are hard-coded to attack specific script types or default HTTP ports:

  • To protect web applications and related databases, use different machines to run each web server, application, and database server.

    The operating systems on these individual machines should be tested for security vulnerabilities and hardened based on best practices.

  • Use built-in web server security features to handle access controls and process isolation, such as the application-isolation feature in IIS. This practice helps ensure that if one web application is attacked, it won’t necessarily put any other applications running on the same server at risk.

  • Use a tool for obscuring your web server’s identity — essentially anonymizing your server. An example is Port 80 Software’s ServerMask.

  • If you’re concerned about platform-specific attacks being carried out against your web application, you can trick the attacker into thinking the web server or operating system is something completely different. Here are a few examples:

    • If you’re running a Microsoft IIS server and applications, you might rename all your ASP scripts to have a .cgi extension.

    • If you’re running a Linux web server, use a program such as IP Personality to change the OS fingerprint so the system looks like it’s running something else.

  • Change your web application to run on a nonstandard port. Change from the default HTTP port 80 or HTTPS port 443 to a high port number, such as 8877, and, if possible, set the server to run as an unprivileged user — that is, something other than system, administrator, root, and so on.

Never ever rely on obscurity alone; it isn’t foolproof. A dedicated attacker might determine that the system isn’t what it claims to be. Still, even with the naysayers, it can be better than nothing.

Put up firewalls

Consider using additional controls to protect your web systems, including the following:

  • A network-based firewall or IPS that can detect and block attacks against web applications. This includes commercial firewalls and Next-Generation IPSs available from such companies as SonicWall, Check Point, and Sourcefire.

  • A host-based web application IPS, such as SecureIIS or ServerDefender.

    These programs can detect web application and certain database attacks in real time and cut them off before they have a chance to do any harm.

Analyze source code

Software development is where security holes begin and should end but rarely do. If you feel confident in your ethical hacking efforts to this point, you can dig deeper to find security flaws in your source code — things that might never be discovered by traditional scanners and hacking techniques but that are problems nonetheless. Fear not!

It’s actually much simpler than it sounds. No, you won’t have to go through the code line by line to see what’s happening. You don’t even need development experience (although it does help).

To do this, you can use a static source code analysis tool, such as those offered by Veracode and Checkmarx. Checkmarx’s CxSuite (more specifically CxDeveloper) is a standalone tool that’s reasonably priced and very comprehensive in its testing of both web applications and mobile apps.

With CxDeveloper, you simply load the Enterprise Client, log in to the application (default credentials are admin@cx/admin), run the Create Scan Wizard to point it to the source code and select your scan policy, click Next, click Run, and you’re off and running.


When the scan completes, you can review the findings and recommended solutions.


CxDeveloper is pretty much all you need to analyze and report on vulnerabilities in your C#, Java, and mobile source code bundled into one simple package. Checkmarx, like Veracode, also offers a cloud-based source code analysis service. If you can get over any hurdles associated with uploading your source code to a third party, these can offer a more efficient and mostly hands-free option for source code analysis.

Source code analysis will often uncover different flaws than traditional web security testing. If you want the most comprehensive level of testing, do both. The extra level of checks offered by source analysis is becoming more and more important with mobile apps. These apps are often full of security holes that many newer software developers didn’t learn about in school.

The bottom line with web security is that if you can show your developers and quality assurance analysts that security begins with them, you can really make a difference in your organization’s overall information security.