Whitelist Form for SPAM Protection: Part II

Whitelist Form for SPAM Protection: Part II

Posted using ShareThis

This post is a continuation of our previous post
Whitelist Form for SPAM Protection: Part I

Here, we have explained the session part mentioned in the code.

Please refer to code samples before moving to the explanation.

Cross-site scripting (XSS) allows code injection of harmful web users in the web pages used by other users. Attackers can do it by using client-side scripts which help them to exploit browser details.

Attackers mainly use this method to hack a site when users browse/enter sensitive data like username, password, bank account number etc. Everything seems fine to the end-user while entering crucial data, but they maybe subject to unauthorized access i.e. they might become a victim of hacking, whereby all their important data are given away to the hackers. This leads to financial and critical data loss.

Here is a solution called Session which can circumvent such hacking problems. Session code is set on the server-side. We can generate a random session key by using md5 for encryption so that the session code is never repeated and stands unique. This code is set as a hidden value in the page which is being browsed by the user. Session codes are never the same. They keep changing with the browser.

This session code can be submitted through URL or as a hidden field. As shown in the code, we check for the session code generated and submitted from the key session. If the person trying to hack the site tries to manipulate user data and submit it, the session code will be different or there will not be any session code. From this, we can check for user intrusion/hacking and stop such hackers from proceeding further.

Using session not only prevents intrusion, but also theft of crucial data by attackers/hackers. Above all, it ensures complete security to end-users.

Source: http://www.dotcominfoway.com/blog