Netsparker Web Application Security Scanner

Top 10 Web Security Checks

When developing your web application or writing it with a framework like Laravel or Django, or anything in between – you should always find yourself in a perpetual state of change => test => change => test, over and over.  You alter your primary CSS file, you test it in your browser; You edit the logic within a function in your code, you test loading that page – you get the idea.

Normally, though, developers are more focused with the functional and visual output of their changes, and spend far less time on the security ramifications.  When they do focus on security, though, commonly the only things that come to mind are typical, like protecting against SQL injections or access control bugs, but a focus on security should cover far more than that.  When testing your web application, this list can give you a good place to start looking for vulnerabilities outside the normal areas.  And while this is nowhere near comprehensive, it will give you at least ten areas you should apply more focus on security to, if you do not already.

1. Unit Testing – Earlier we mentioned a perpetual state of change => test => change => test.  A problem with this, however, is when your changes affect things other than what you are testing, such as a function that is used in multiple areas of your code.  Testing frameworks allow you to ensure intended functionality by running functions with certain parameters and asserting expected results occur, preventing security incidents from occurring (e.g. preventing an isAdmin() function from falsely allowing admin rights).

2. Access Control – We also mentioned access control bugs, which in custom-developed applications are crucial to find.  This would be things like the ability for a user to escalate their own privileges, or access content they are normally unauthorized to access.  Elevated rights to perform actions and content that is restricted should be verified as being under the appropriate access control restrictions.

3. Change Tracking/Version Control – Keeping track of changes to code or configuration files is critical for many security concerns: functional reliability, tracking who did what, ensuring a hacker did not change anything, and much more.  Tracking configuration file changes (like with Tripwire) and using source code management (Git, SVN) guarantees a log of what changed when and by who.

4. Administrative Rights – As you work in larger teams, the number of people with admin-level rights to things may increase.  Not just root privileges on servers, but write access to Git repositories, or EC2 instance access in the AWS account.  Audit logs help keep a trail of who did what, but what is more important is ensuring the right people have just the amount of access they need.

5. Least Privilege – Continuing on from the Administrative Rights bullet above, a concept of least privilege should always be employed against both services and people.  When granting access to anything, an important question to consider is, What is the least amount of privileges this needs?  A web application does not need access to the whole file system, a forum moderator does not need access to the database, and so on.

6. Offsite Redundancy – Most of the previously mentioned points require some level of logging to be fully effective.  Storing logs locally, as opposed to remotely, allows for a possibility of audit trails being tampered with.  Additionally, offsite backups and multi-geographic redundant web services allow for better stability, uptime, and disaster recovery.

7. Monitoring – Redundancy is good for recovery, but up-to-the-minute knowledge is better.  Rather than find out hours, maybe even days later that a problem occurred, obsessive monitoring can tell you the moment a problem occurs so you can handle it before a major outage happens.  Good monitoring also looks for the possibility of cascade effects, such as one service outage taking down an entire cluster of other services that rely upon it.

8. Encryption – Far too many web applications still allow plaintext authentication over non-SSL connections and various other unencrypted traffic.  Data is also not always securely stored, such as passwords stored with easily crackable and weak MD5 or SHA1 password cryptographic hashing algorithms.  Ensuring constant use of cryptographically secure TLS certificates and hashing algorithms (salted SHA512 is recommended) significantly reduces the vulnerability of unauthorized data access.

9. Web Security Scanners – With every function and every user input you add to your application, the possibility of security risk increases exponentially.  It is impossible for even a whole team of security auditors to manually verify and test everything, but a good automated web security scanner can not only test for vulnerabilities, but also ensure proper access controls exist and look for things a developer might not otherwise consider.

10. SQL Injections – Of course, this list would not be complete without talking about the obvious; SQL Injection. The first instance of SQL injection was discovered 15 years ago and after all these years, SQL Injection is still #1 in the OWASP top 10. Using prepared SQL statements and sanitizing user input are two great ways to prevent getting caught in that number-one problem.

As we said previously, this list is by no means comprehensive.  Indeed, a truly comprehensive list would number a potentially into the thousands and become a volume of books in their own right.  But security is about understanding every potential edge and corner case, thinking way beyond ‘outside-the-box,’ and realizing that preventing SQL injections and exploits are not the only way to secure a web application.
If you are not regular reader of this website then highly recommends you to Sign up for our free email newsletter!! Sign up just providing your email address below:

Enter your email address:

Check email in your inbox for confirmation to get latest updates Software Testing for free.

Happy Testing!!!

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>