We programmers are faced different types of security problems in our development life cycles. Some people spend a lot of their time to fix the unwanted errors .But some basic precautions should be taken to reduce these problems. I came across several sites which tell you how to improve your website security, and I share it with you here.

XSS

Many web-developers are familiar with Cross Site Scripting attacks, often known as XSS, which are usually the result of not filtering input to applications.

A standard example would be a message-board, or forum, which allowed users to login and post messages which would be displayed literally – so a malicious user could create a message reading:

alert(“hii”);

This would then result in an alert being displayed by subsequent visitors who viewed the message if they had javascript enabled.

The root cause of these security issues is trust. The implement or of the forum or message board trusted the users input and didn’t sanitize it appropriately.

The XSS attacks exploit that weakness to steal cookies, etc.

CSRF

“Cross Site Request Forging” is the another name for a new problem, or one new to me at least.

The root cause of the CSRF attacks is also trust. The trust of a website by a user of that site. This trust is exhibited by the fact that the user never, or only rarely, logs out.

In a typical scenario the communications between a webserver and client browser looks like this:

  • Client makes a request to the server.
  • The server responds.
  • The client displays/uses the response.

For example to create a new weblog entry the user would browse to this site,

Now consider what happens if a malicious external site were to copy the “add weblog entry” form and host it upon their site.

They could change the wording, hide the fields, etc. But ultimately there is nothing stopping them from hosting a modified version of the form – and serving it to users.

This is where the cross-site issue comes into play. If that remote site can coerce, persuade, or trick a user logged into this site to submit the form then the request will be processed by this site using their cached credentials.

Because they trust this site, and have remained logged in, the submission would be processed and the unsuspecting user would have a new weblog entry posted which they didn’t explicitly write, or expect. For example “I like cheese.”

Step by step the attack works like this:

  • External site copies a form from this one.
  • External site persuades/cajoles/tricks a user who remains logged in here to visit their site and submit the form.
    • Perhaps via javascript magic.
  • The server here receives the form submission and proceses it
    • Because it doesn’t realise the form came from a malicious remote source.
    • And because the user was logged in any authentication tests succeed.
  • The user now arrives at this site with new content posted in their name.

The solution to this problem is potentially invasive but conceptually simple. Rather than serving forms to clients and then processing them without regard to the submission source the forms each include a “session token”.

When a form is submitted this token is examined, and if it matches the token which was sent with the form the processing occurs, if it doesnt an alert is raised.

This utterly prevents the attack because it means that the malicious remote server cannot serve a valid form – it can’t predict the secret form session token, so the submission will always fail.

(There are simpler solutions involving the use of the HTTP Referer (sic) header, but these are unreliable as this information might be forged or not present.)

It is worth noting that many sites fail to verify the submission of forms in this manner, so they are potentially at risk of malicious (ab)use of their forms.

Described below are 3 changes that you can make to your site to enhance security :

Cookie Safety

Microsoft’s Internet Explorer supports an extension to cookies called “httponly”. The intention of this support is that the cookies served by a site will be marked as unavailable for scripting use.

This means that if there were an XSS attack available in this site then users of that browser wouldn’t be vulnerable to cookie/session theft.

A bug was filed against Mozilla, but progress appears to have stalled (#7456).

(IE comprises about 9% of visitors to this site, certainly not the majority. However the change involved is sufficiently minimal that it is worth doing just to mitigate any future attacks.)

Session Safety

Make it possible to choose “secure” login for your site. This actually ties the users login session to the users IP address.

Again this offers no increased security in the normal course of events, but if there were ever to be a security issue which resulted in a cookie or session theft due to XSS, or similar, then you would be protected if you chose this option.

There is small guide to this facility linked to from the login form.

Cross-Site Request Forgery Protection

You can insert a “session token” in each significant form, which will prevent the processing of rogue submissions rather than end-user page views.

For more information look at :

http://www.debian-administration.org/articles/465

http://www.debian-administration.org/article/Improving_website_security

Latest posts by Koushik Nandy

  • Share/Bookmark