..::You can change the world with the knowledge::..

Open Web Application Security Project (OWASP) is an open source project that was built to find the cause of insecurity is a software and discover how to handle it. There are 10 web application security loopholes are found and their recommendations about the deal as a minimum safety standard of the web application.
Here are 10 hole, and the way that we can resolve the issue.

I. Unvalidated input 
All web application displaying data from the HTTP request made by the user and uses that data to perform operations. Hackers can manipulate the parts on request (query string, cookie information, headers) to bypass the security mechanisms.
Here are three types of attacks associated with this problem:
• Cross site scripting 
• Buffer overflows 
• Injection flaws 
There are several things to note when dealing with the validation of our application. First, it is not good to believe in the web application on the client side scripting. The script usually stop form submission when there is an incorrect input. However, the script can not prevent hackers to create their own HTTP request, which is free of the form. Using a client-side validation can still make a vulnerable web application.
Second, some applications use a "negative" (negative approach) on the validation: The application tries to detect if there is a dangerous element in the request parameters. Problems of this type of approach is only able to protect against some attacks, namely: only attacks that are recognized by the validation code that is preventable. There are many ways in which hackers can bypass the security of unvalidated input; There is still a possibility that the new way is not recognized by the application can bypass validation and do the destruction. Is a better way to use a "positive" (positive approach), namely: limiting a format or pattern to the permitted values ​​and ensure input in accordance with the format.

II. Broken Access Control 
Many applications are user-user should categorize into different roles and different levels to interact with content that is distinguished from these categories. One example, many applications that are user role and admin role: only the admin role are allowed to access specific pages or administration action.
The problem is that some applications are not effective for this work force so that authorization. For example, some programs only use a checkpoint where only selected users can access: for further processing, the user must prove himself authorized by using the user name and password. However, they do not run the checks from the previous checkpoint: which if the user successfully passes the login page, they can freely run the operation.

Another problem associated with access control are:
• Insecure IDs - Some sites use the id or key that points to the user or function. ID can also be guessed, and if the hackers can easily guess the ID of the user who terautorisasi, then the site will be easily attacked.
• File Permissions - Many web and application server is believed to external file that holds a list of authorized users and resources anywhere that can and / or inaccessible. If the file is readable from the outside, then the hacker can easily modify to add itself to the list of permitted users.
What steps can be done to solve it? In these examples, we can develop a filter or a component that can be run on sensitive resources. Filters or components can be designated to ensure only authorized users can mengakases. To protect from insecure IDS, we must develop our application in order not to believe in the confidentiality of the IDs that can provide access control. On the issue of file permissions, the files must be in a location not accessible by web browsers and only certain roles can access them.

III. Broken Authentication and Session Management 
Authentication and session management refers to all aspects of managing user authentication and management of an active session. Here are a few things to note:
• Password strength - our application should provide a minimum level of security of a password, which can be seen by looking at the length of the password and complexity. For example an application where there are new users that will register: the application does not allow passwords with a length of 3-4 characters or simple words that can be easily guessed by hackers.
• Password use - The application we have to restrict users who access the application to log back into the system at a certain time limit. In this way the application can be protected from a brute force attack where hackers can attack repeatedly to successfully log into the system. In addition, the log in which failed should be noted as information to the administrator to indicate the possibility that the attack occurred.
• Password storage - the password should not be stored in the application. Passwords should be stored in encrypted format and stored in another file like a database file or password file. This can ensure that sensitive information such as passwords are not propagated into the application.
Another related issue: the password should not be in the form of hardcoded in the source code.
• Session ID Protection - servers usually use the session Id to identify the user who entered the session. However, if the session ID can be seen by someone on the same network, the person may become a client.
One way that can be used to prevent the invisibility of the session ID by someone in a similar network is to connect the communication between servers and clients on an SSL-protected channel.

IV.Cross site scripting 
Cross site scripting occurs when a person makes a web application through script to another user. This is done by an attacker to add content (such as JavaScript, ActiveX, Flash) in the request that can create HTML output that can be viewed by other users. If there are other users who access content, the browser does not know that the page can not be trusted.
Way that can be used to prevent cross-site scripting attacks is to validate the data entry of user requests (such as headers, cookies, user parameters, ...). How to not use negative approach: try to filter active content that is not an effective way.

V. Buffer overflows 
Attackers can use buffer overflows to damage the web application. This is done because the attacker sends requests that cause the server to run code sent by the attacker.
Buffer overflow weakness is usually difficult to detect and hard done by hackers. But the attacker still can find these weaknesses and make the buffer overflow on some web application.
Thanks for the design of the Java environment, where applications running on J2EE servers are safe from this type of attack.
To ensure security, the best way is to conduct surveillance if there are any patches or bug reports for the server products that are used.

VI. Injection flaws
One disadvantage is that popular injection flaw, which the hacker can send or menginject request to the operating system or to external sources such as databases.
One form is SQL injection. Here is one example of SQL injection:
http://someServer/someApp/someAction?searchString=jedi 
URL above will process the search with the keyword 'Jedi'. Implementations where there is no input validation is like the following SQL code:
select * from someTable where someField = 'value' 
where the value is the value of searchString parameters that exist in the HTTP request.
What if, hackers do input from the URL like this:
http://someServer/someApp/someAction?searchString=jedi '% 20and% 20true; 
% 20DROP% 20DATABASE; ' 
SQL query is formed like this:
select * from someTable where someField = 'Jedi' AND true; DROP DATABASE;'' 
Initial statement would be acceptable where there is a clause AND TRUE. And then the DROP DATABASE statement will also be execution that will give damage to the application.
This attack could possibly occur because the input is not validated. There are two ways you can do to prevent this attack are:
• Instead of using SELECT statements, INSERT, UPDATE and DELETE statements, can be made a function that do the same. By using the existing safeguards against the parameters expected. In addition to the function, the parameters that enter must be the same as the data type of the declared parameters.
• Right to access the application should also be restricted. For example, if the application seeks only to see the data, need not be given permissions to perform INSERT, UPDATE or DELETE. Do not use an admin account on a web application for mengakases database. It can also meminimailkan attacks from hackers.

VIII. Insecure storage 
Web applications typically need to store sensitive information like passwords, credit card information, and others. Because these items are sensitive items that need to be encrypted to prevent access directly. However, several encryption methods are still weak and still be attacked.
Here are some common mistakes:
• Mistakes to encrypt critical data
• No safe keys, certificates, and passwords
• Lack of safe storage location of data
• Lack of randomization count
• Errors selection algorithm
• Trying to create a new encryption algorithm
Based on the following scenario: There is an application, where there is a password on the user object. However, the application stores the user object into the session after the user login. The problems that will arise in this scenario is that the password can be viewed by someone who can see the session of that user.
One way to avoid mistakes made storage of sensitive information is: do not make the password as an attribute of a class that represents user information; Rather than encrypting credit card numbers from the user, it is better to ask about it whenever needed.
In addition, using existing encryption algorithms will be better than making your own algorithm. You just make sure the algorithm to be used has been recognized by the public and totally reliable.

IX. Denial of Service 
Denial of Service is an attack made by a hacker who sends the request in a very large amount and at the same time. Due to these requests, the server becomes overloaded and can not serve other users.
DoS attacks are able to spend bandwidth on the server machine. Moreover, it can also spend a memory, database connections, and other sources.
It is generally very difficult to protect these applications from attacks. However, there are still ways to do such as limiting the resources that are accessible user in a minimal amount. An idea / a good way to make the load quotas that limit the amount of load data to be accessible to users of the system.
One example is the implementation of the bulletin board: user restrictions at the time of search, where these operations can only be done every 20 seconds. In this way it is certain that the user can not spend the connection from the database.
Another solution is to design a web application where users are not authorized to have access to only a little or no access to web content associated with the database.

X. Insecure Configuration Management 
Usually the group (group) who developed different applications to groups that arrange the hosting of the application. This could be dangerous, because security is reliable only in terms of application: sedangakan terms of the server also has the security aspects that need attention. An error of server configuration can pass through the security aspect in terms of application.
Here is a server configuration error that could cause problems:
• Vulnerabilities that have not patched the software on the server - the administrator is not to patch existing software on the server.
• Vulnerabilities in which the server can display a list of directory or a directory traversal attack also.
• backup files or file sample (sample file), script files, configuration files are left behind / not necessary.
• Right to access the directory or file is wrong.
• Presence services such as remote administration and content management are still active.
• Use the default account and default password.
• administrative functions or debugging functions that can be accessed.
• There is an informative error messages from a technical point.
• configuration error SSL certificate and encryption settings.
• Use self-Signet certificates for authentication.
• Use the default certificate.
• Errors authentication with external systems.