Network World
Thursday, November 12, 2009
DNSstuff.com
Get information about your IP
IP Information
50+ On-demand DNS and network tools

The trouble with programming

Related links

Security Notes RSS feed

E-mail Ellen Messmer

Security Notes archive.

Security forum
Discuss Security Notes and other Security topics.


Bank One's vice president and manager of information security, Matt Dokman, and Ian Rathie, the bank's information systems director in charge of application security, have the mind-boggling responsibility of keeping a major financial institution's operations safe from attack. They recently shared their views on where they see some of the biggest challenges.

While not discounting network-based attacks, "the biggest concern right now is attacks coming from the application layer," says Rathie. This occurs when attackers attempt to exploit subtle weaknesses that might be found in either commercial off-the-shelf products or custom code to trick their way into back-end resources. "They're effectively using the institution's code to attack," Rathie points out.

While there are many types of application-layer attack, "the worst problems are cross-site scripting and SQL injection," Rathie said.

In his excellent new book "Malware: Fighting Malicious Code," author Ed Skoudis provides a lucid explanation of all this. On SQL injection, Skoudis write: "Beyond buffer overflows, consider Web applications, such as online banking, electronic government, or other services, that utilize a Structured Query Language database to store information. In a SQL injection attack against such applications, a bad guy sends database commands inside of user input. The user might be expected to provide an account number, but an attacker instead provides a line of SQL code that dumps information from the database in an unauthorized fashion. If the application doesn't screen out such a command, the database will execute it, giving the attacker raw access to a Web application's database."

Skoudis is also helpful in defining cross-site scripting (which goes by the acronym XSS) by describing it as: "the attacker injects malicious code into a vulnerable Web site so that the visitor's browser inadvertently executes the code."

The end result is that "as far as the browser is concerned, the script is coming from the site that is authorized to access the cookie and other page elements, and readily hands over control to the attacker."

Skoudis notes: "Unfortunately, XSS security flaws continue to plague search engine, discussion, shopping, and financial sites that you and I use."

Dokman points out that there are attacks that allow the intruder to masquerade as a legitimate bank customer and steal passwords. Dokman and Rathie believe the vast majority of these attacks can be prevented by using tools such as application scanners and plenty of code review to plug holes that programmers may leave in applications before the public has access to them. Application firewalls can also be put in place to block attacks aimed at exploiting application weaknesses.

In the end, the problem arises from poor programming practices.

"Programmers aren't trained in how to do this properly," says Rathie. "Buffer overflows are clearly a result of poor programming. They're not checking input and output."

Dokman and Rathie suspect there's not enough emphasis put on security-conscious programming in colleges today. Programmers often need extra training to make sure they follow coding practices that don't allow applications to be manipulated by attackers.

Like other banks and brokerages, Bank One relies on extensive testing of applications, with help from both internal and external resources, to prevent application-layer break-ins. "It's a matter of getting your programmers to program properly," Rathie concludes.

Back to Security Notes

Comments

Post a comment

Name:


E-mail address:


URL:


Comments:


Remember info?