The vulnerability checking stage is to ensure that your site is as secure as possible. There are many different factors that can attribute to how in-depth you are required to go with this section. Some of these factors include which scripts you are using, and what you are using them for.
If you have a contact form where data is collected, processed (with PHP or some other server side script) and stored in a database, then it is important that your site is checked for common exploitations like SQL Injection.
SQL Injection is just one potential form of site vulnerability, here’s our list of common examples along with very brief explanations:
This is a very common form of vulnerability, this is where an attacker enters SQL into an unsanitised user input, allowing them to extend the original query or run another query altogether.
XSS – Cross Site Scripting
This is when a malicious script is inserted into a website, again normally by an unsanitised user input.
Click jacking is where a visitor’s mouse click is used in a way outside of the visitor’s intentions. This can be achieved by placing an iframe behind some clickable content like a game.
Cookie or Session Manipulation
A user’s session can be kept active using a cookie, these cookies may contain the user’s unique ID number. An attacker could could gain access to a user’s account by manipulating the ID number in the cookie.
Information leaking can occur with websites that have been left in debug/development mode. While in this state, error logs may still continue to be created, therefore giving the attacker potentially useful information about your site.
We’ve only scraped the surface of site vulnerabilities and how to mitigate them, if you want to learn more we suggest taking a peek at, http://www.websecurify.com/overview/vulnerabilities.html.
As you may have determined, there are many risks online that can add difficulty to a web developers job. There are a number of ways you protect yourself from the vulnerabilities, however each vulnerability has to be dealt with in a particular way. You can test for them manually by testing user input fields with bad characters, for example quotation marks. You may find it quicker to use a vulnerability scanner like Burp Suite or Vega (which is open source). Here are a couple of links to get you started.
Download link for Vega: https://subgraph.com/vega/download/
Vega help files can be found here: https://subgraph.com/vega/documentation/