Any Web Application that we develop must be secure and safe. We cannot just create an application that can be accessed/modified by every tom, dick and harry of this world. Though this topic is in no way related to the deployment descriptor or the deployment of a web application, I thought, this is the best place to cover this. Because, we are almost at the fag end of our journey towards SCWCD certification.
So, lets get started!!!
Why do we need Application Security?
The security issues are ever present in software, and more so for Web applications because you are exposing part of your machinery to the Internet. If you have been using the internet for sometime, you must be aware of hackers, spammers and all sorts of pain on the backside problems. So the best way to be is “Better Safe than Sorry”. Sun made a big effort to make Java secure, whether as a standalone or Web application. This is to ensure that our websites do not become a joke because of some crazy hacker’s efforts.
There is no end to the imagination of those who can't compete within society's rules. You should design your Web application to withstand at least a minimum level of attack, which is sometimes just an accident, or so we like to hope.
Important Terms in Application Security:
• Authentication - The means by which communicating entities prove to one another that they are acting on behalf of specific identities. Are you really you?
• Authorization - This is access control where interactions with resources are limited to collections of users or programs for the purpose of enforcing integrity, confidentiality, or availability constraints. You have permission to use a given page.
• Data integrity - The means used to prove that information has not been modified by a third party while in transit. The data is really what was sent.
• Auditing - Maintain a record of Web application activity. For example, you can log resource accesses including times and requester IP and ID. This usually involves a log somewhere.
• Malicious code - Code that deliberately behaves in a way other than advertised, especially to compromise your server.
• Web site attacks - An attempt to compromise your Web site. The most popular attack is the denial-of-service attack where the attacker floods the server with requests, reducing its capacity to service legitimate requests.
Authentication Types
As mentioned previously, authentication is the mechanism that verifies, you are really who you say you are. Somehow, the Web client has to prove to your Web application its identity. There are four ways to do that including HTTP Basic, HTTP Digest, HTTPS Client, and Form Based authentication.
The following list defines each of the authentication types in the objective:
• HTTP Basic Authentication - Authentication based on a username and password. It is the authentication mechanism defined in the HTTP/1.0 specification. A Web server requests a Web client to authenticate the user. The Web client obtains the username and the password from the user and transmits them to the Web server. The Web server then authenticates the user. This is the lowest level security of the four here.
• HTTP Digest Authentication - The password is encrypted. Like HTTP Basic Authentication, HTTP Digest Authentication authenticates a user based on a username and a password. However, the authentication is performed by transmitting the password in an encrypted form.
• HTTPS Client Authentication - This is end user authentication using HTTPS (HTTP over SSL). This mechanism uses public key encryption, which requires the user to possess a Public Key Certificate (PKC). This is the highest level security of the four here.
• Form Based Authentication - This is similar to Basic except that a form is used with predefined fields. These fields must be named j_username and j_password, respectively and the form method and action must be named POST and j_security_check, respectively. Ex:
< form method="POST" action="j_security_check" >
< input type="text" name="j_username" >
< input type="password" name="j_password" >
< / form >
All four of the security mechanisms can be used singly; you can only select one authentication mechanism for a single WebApp. However, if you need real security, I would suggest, you choose SSL.
Previous Chapter: Chapter 49 - Web Application Exceptions
Next Chapter: Quick Recap - Chapters 47 to 50
No comments:
Post a Comment