Rankspike

In the next coming articles to, I will be focusing on Web application securities, as a developer nowadays, it’s imperative that we are very familiar with different vulnerabilities and types of attacks that are going on, we should not only be aware but it should be cultivated in our minds whenever we develop a public facing applications.

A lot of times, due to budget, or the types of projects we handle, we forget to consider different vulnerabilities which might affect our client’s web site, which shouldn’t be the case, it should be a criteria as part of development to make sure that no matter what type of web projects you’re working on specially when dealing with sensitive data, security should always be part of it.

A simple encoding of forms before we handle them is a huge matter, this is where most DOS (denial-0f-service) attacks originate, making sure that every aspect of business rules should combine security measures always remember; it is always easier to secure simple logic functions than complex logic functions.

In this first part I’d like to talk about the basic building block of a web application, Single transaction, this is the single way of accessing an object. Making single transaction secure will give the developer safe building blocks, which can be used to create more complex entities.

• Encoding of the transaction
• Parameter values within the transaction
• Obfuscate if possible
• Dynamic Page Creation
• Usage of HTTP headers

Let’s talk about this in more details;

Encoding Transactions. The application must establish a single encoding scheme for each request (preferably common to all requests within an application) during the design stage,which is non-ambiguous and has a single representation. The decoding function should be the first to be invoked during transaction processing, this will allow you to validate all entries before committing to the next stage.

Parameter values within the transaction. A transaction is built from an object name and parameter values for the object to operate
upon. It is crucial to protect the parameters enforcing their validity and fit with the application logic. An attacker of the web application may change the value of any parameters sent to the server. As a result, nothing can be assumed about this input.

Obfuscate if possible. When creating and receiving transactions we should always find a way to disturb the information and make it confusing to the public but not to the system logic, putting this kind of strategy in place will prevent hackers and other attacker’s easy guessing your application.

Dynamic Page Creation. Dynamic sites are based on the ability to provide users with a tailored experience, created for his specific profile and session. As part of this process, aspects of the user input should be taken into account to create the dynamic pages sent back to the user. Never use values received from the client to directly create dynamic pages. Implanting users’ input directly within pages can lead to severe consequences.

Usage of HTTP headers. HTTP headers raise security issues. Similar to all other information from the client, these fields are easily manipulated. Therefore, while they might be used to provide certain functionality, they should never be used to provide security. A good example is the REFERER header, which reflects the page leading to the transaction. It can be manipulated to contain any desired URL.

These are just guides, depending on your application design and business rules every security measures within your applications should always be tailored to ensure compatibility.

Go to Next part of this series >.