6. Security Miss-configuration
Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date, including all code libraries used by the application.
There’s a perpetual buzz around software flaws and exploits researchers disclose daily, but security experts say it often distracts IT pros from a growing and more serious problem — networks so sloppily configured and maintained that the bad guys can drive a virtual bulldozer through them without attracting attention.
The problem runs the gamut from mismatched applications and hardware, security systems that are put in place but not regularly maintained to wireless access points that are opened with no defenses attached, according to IT consultants who have seen the problems first hand.
[youtube]http://www.youtube.com/watch?v=XmUQ13NCNd8[/youtube]
5. Cross Site Request Forgery
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
CSRF vulnerabilities have been known and in some cases exploited since the 1990s. Because it is carried out from the user’s IP address, some website logs might not have evidence of CSRF. Exploits are under-reported, at least publicly, and as of 2007 there are few well-documented examples. About 18 million users of eBay’s Internet Auction Co. at Auction.co.kr in Korea lost personal information in February 2008. Customers of a bank in Mexico were attacked in early 2008 with an image tag in email. The link in the image tag changed the DNS entry for the bank in their ADSL router to point to a malicious website, impersonating the bank.
[youtube]http://www.youtube.com/watch?v=olSxxfUM7-U[/youtube]
4. Insecure Direct Object References
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. An attacker can manipulate direct object references to access other objects without authorization, unless an access control check is in place.
For example, in Internet Banking applications, it is common to use the account number as the primary key. Therefore, it is tempting to use the account number directly in the web interface. Even if the developers have used parameterized SQL queries to prevent SQL injection, if there is no extra check that the user is the account holder and authorized to see the account, an attacker tampering with the account number parameter can see or change all accounts.
The best protection is to avoid exposing direct object references to users by using an index, indirect reference map, or other indirect method that is easy to validate. If a direct object reference must be used, ensure that the user is authorized before using it.
[youtube]http://www.youtube.com/watch?v=q9sMSxvdp6E[/youtube]
