A simple way to look at web application security is by picturing your residence. It’s a front door, a rear door, windows, quite a few rooms, a roof, boundary fences and distinct access routes. Only the terminology differs.
The Front Door.
The front door of any web application is the login page and, unsurprisingly, it’s the principal point of attack. A login page will consist of edit boxes to form a user name and password along with a button to ship these to your server to authenticate your access to the remainder of the web application. Some login pages may offer a captcha to be certain you’re a human being and not a mock-up of the exact same form on another server. The mock-up form will cycle via variants of consumer names and passwords until it increases access to the program. This is referred to as cross-site forgery and is comparable to your burglar forging the secrets into your residence.
Captchas are jumbled pictures of scrambled letters and figures that make it impossible for an automatic script to read. Regrettably, as the scripts become adept in reading these pictures, the captcha images will need to become more complicated and more difficult for people to read. This causes frustration for the end-user as they’ve repeated failed attempts at gaining access to their accounts since the captcha was unreadable. The answer for this is to replace the captcha using a secure token. The secure token is generated my joining the user name, password and any other user info available with a distinctively generated key. This concatenation is then encrypted and stored as a hidden field in the form, thus rendering it impossible for any mock-up form to generate a successful login effort.
The Windows and Back Door.
What are the windows of a web program? I don’t mean that the operating system on the server. I’m speaking about possible areas of each page that may be broken to make a forced entry. These regions are edit boxes and text areas which allow a user to type information. An attacker will use edit boxes and text areas to input commands that the database understands. If the software isn’t written securely then it’s extremely simple to disrupt the database when it’s saving the information, so it will execute the commands provided by the attacker. Normal attacks could lead to the database being destroyed, data being stolen or consumer information being compromised. This sort of attack is called SQL injection.
To stop cross-site scripting, the computer software must scan all of editable places for code and also incorporate a secure token in each and every URL and link. Just as gaps and holes in fences should be shut. All secure pages should check for the occurrence of an authenticated user.