Secure Coding Basics

Most developers are reluctant to take the responsibility in security and assume that this is the job of web administrators and network engineers. You may have best infra in terms of security but if your developers are not writing secure code your system can easily be hacked.

Security is a broad concept but I just want to give some simple examples and speak about best practices in secure code writing.

First of all there is no fully secured system. If you want a fully secure system just turned off the serverJ
What is our job in terms of security is making the attack surface smaller and making our systems much more secure. We should also keep in mind that security is an ongoing process and we should continuously review our applications in terms of security.

Let’s speak on some of the well known attack technics with examples;

Sql Injection

SQL Injection happens when a malicious user manipulates the data input in such a manner to perform other operations against the database or any resource in the server. Think that we have a webpage asking for username and password and after validating this username and password we are authenticating the user.

My sql query is ;

string strQry = “SELECT Count(*) FROM M_USERS WHERE UserName='” + txtUser.Text + “‘ AND Password='” + txtPassword.Text + “‘”;

If the count is more than 0 this means password is correct and in normal scenario I will have a query like this


SELECT Count(*) FROM M_USERS WHERE UserName = ‘KORFEZ’ AND Password= ‘pswd’;

But fraud login scenario an attacker can use such values and change the query



SELECT Count(*) FROM M_USERS WHERE UserName=’KORFEZ’ Or 1=1 –‘ AND Password=’XXXX

1=1 everytime and return of this query is more than 0 everytimeJ Attacker is in…

Take another example ;


This is a car passing through an automatic passing system (which is reading plate numbers) with a manipulated plate numberJ and dropping the database. This is just for humor but if you were the victim of such an attack it would not be funny for youJ

Cross Site Scripting (XSS)

XSS exploit vulnerabilities in web page validation by injecting client-side script code into a vulnerable application.

Let’s continue with an example

This is an internet banking webpage to transfer money to another customer. I am adding a javascript to the description textbox.

When the victim customer wants to see his/her transactions, an alert pops-up


You may think that this is just a simple alert but I can also write a script which pops-up a site and send session id of the user and hijack user’s session.

There are more attack technics but what can we do in order not to be the victims of such attacks.

Adopt the principle of least privilege. The principle of least privilege requires that an individual, program or system process is not granted any more access privileges than are necessary to perform the task. Processes that run script or execute code should run under a least privileged account to limit the potential damage that can be done if the process is compromised.

Don’t trust user input. Applications should thoroughly validate all user input before performing operations with that input. The validation may include filtering out special characters. This preventive measure protects the application against accidental misuse or deliberate attacks by people who are attempting to inject malicious commands into the system.

Don’t rely on security by obscurity. Trying to hide secrets by using misleading variable names or storing them in odd file locations does not provide security. In a game of hide-and-seek, it’s better to use platform
features or proven techniques for securing your data.

Assume external systems are insecure. If you don’t own it, don’t assume security is taken care of for you.

Reduce surface area. Avoid exposing information that is not required. By doing so, you are potentially opening doors that can lead to additional vulnerabilities. Also, handle errors gracefully; don’t expose any more information than is required when returning an error message to the end user.

Fail to a secure mode. If your application fails, make sure it does not leave sensitive data unprotected. Also, do not provide too much detail in error messages; meaning don’t include details that could help an attacker exploit a vulnerability in your application. Write detailed error information to the Windows event log.

Remember you are only as secure as your weakest link.
Security is a concern across all of your application tiers.

Comments (2)

  1. ceegee says:

    Your screen shots for the Cross-site scripting example are way too small to read.  Can you post larger images and/or and text to show what you were doing?

  2. It is just a javascript alert between script tags. Although this seems to be harmless you can also write a javascript which pops up a web page and passes session_id or something else to the page created by the attacker.