Apache Security - Ivan Ristic [145]
Deprecate insecure authentication methods, such as Basic authentication, because they send user credentials to the site verbatim.
Design new authentication methods (or upgrade Digest implementations) to allow for mutual authentication (clients to servers and servers to clients).
Upgrade the existing protocols to take the human factor into account as well.
Design better client applications (as discussed in the section Section 4.2.2 in Chapter 4).
Continue educating users.
No quick remedies will be created for the phishing problem, since none of the ideas will be easy to implement. The following resources are useful if you want to learn more about this subject:
Anti-Phishing Working Group (http://www.antiphishing.org)
"The Phishing Guide" by Gunter Ollmann (NGS) (http://www.nextgenss.com/papers/NISR-WP-Phishing.pdf)
Application Logic Flaws
Application logic flaws are the result of a lack of understanding of the web application programming model. Programmers are often deceived when something looks right and they believe it works right too. Most flaws can be tracked down to two basic errors:
Information that comes from the client is trusted and no (or little) validation is performed.
Process state is not maintained on the server (in the application).
I explain the errors and the flaws resulting from them through a series of examples.
Cookies and Hidden Fields
Information stored in cookies and hidden form fields is not visible to the naked eye. However, it can be accessed easily by viewing the web page source (in the case of hidden fields) or configuring the browser to display cookies as they arrive. Browsers in general do not allow anyone to change this information, but it can be done with proper tools. (Paros, described in the Appendix A, is one such tool.)
Because browsers do not allow anyone to change cookie information, some programmers use cookies to store sensitive information (application data). They send cookies to the client, accept them back, and then use the application data from the cookie in the application. However, the data has already been tainted.
Imagine an application that uses cookies to authenticate user sessions. Upon successful authentication, the application sends the following cookie to the client (I have emphasized the application data):
Set-Cookie: authenticated=true; path=/; domain=www.example.com
The application assumes that whoever has a cookie named authenticated containing true is an authenticated user. With such a concept of security, the attacker only needs to forge a cookie with the same content and access the application without knowing the username or the password.
It is a similar story with hidden fields. When there is a need in the application to perform a two-step process, programmers will often perform half of the processing in the first step, display step one results to the user in a page, and transmit some internal data into the second step using hidden fields. Though browsers provide no means for users to change the hidden fields, specialized tools can. The correct approach is to use the early steps only to collect and validate data and then repeat validation and perform the main task in the final step.
Allowing users to interfere with application internal data often results in attackers being able to do the following:
Change product price (usually found in simpler shopping carts)
Gain administrative privileges (vertical privilege escalation)
Impersonate other users (horizontal privilege escalation)
An example of this type of flaw can be found in numerous form-to-email scripts. To enable web designers to have data sent to email without a need to do any programming, all data is stored as hidden form fields: