Filling Out Forms: Still a Dangerous GameFilling Out Forms: Still a Dangerous Game
Despite upgrades and fixes, most browsers are still vulnerable to attacks via Web forms, researcher says
June 20, 2008
It may not sound too scary, but filling out forms on the Web is still a dicey business, a researcher said this week.
In an update of his 2002 paper, which exposed many of the vulnerabilities associated with HTML forms, EnableSecurity's Sandro Gauci states that most browsers still haven't completely fixed the problems associated with commonly used forms.
"Does it still work? The short answer is yes," Gauci says in the updated paper. "Most popular Web browsers seem to block certain well-known ports. However, there are many cases where an attacker can make use of ports which are not on the blacklist." And Internet Explorer and Opera don't block as many ports as Safari or Firefox, he says.
The problem, in part, is that most browsers do their best to render any data they receive in HTML, Gauci explains. While the browser vendors have generally shored up the vulnerabilities in Web forms that are exchanged with an HTML server, most of them have done little about the exchange of forms between a browser and a non-HTTP server, such as an FTP or SMTP server.
Since the browser has no way of distinguishing between an HTTP server and a non-HTTP server, a user might be enticed to browse to a non-HTTP server, which would typically send an error message to the browser, the paper says. But a wily hacker might be able to attach malicious code to the error message, and potentially launch a cross-site scripting (XSS) attack or steal data from the browser that would allow him to gain access to the user's information or take over the user's machine. .
"When an attacker can control what is returned by the server, the victim becomes vulnerable to security issues such as [XSS]," Gauci writes. "In the case of HTTP servers, this is a well-known issue, and therefore modern Web servers do not exhibit this behavior by default.
"However, this is not the case with other kinds of servers, such as SMTP or FTP servers, [which] often echo back error messages containing user input," the paper observes. "When this user input can be controlled by the attacker, bad things can happen."
To repair the vulnerability, browser vendors will need to re-tool their browsers so that they do not attempt to render responses from non-HTTP servers in HTML, Gauci says.
"One solution would be to check the HTTP response headers and make sure that they are indeed HTTP 1.0 or 1.1-compliant," he says. "This would identify IMAP or FTP servers responding with malicious HTML. When the HTTP response headers are not found, the Web browser should not render the content as HTML."
Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.
About the Author(s)
You May Also Like
Hacking Your Digital Identity: How Cybercriminals Can and Will Get Around Your Authentication MethodsOct 26, 2023
Modern Supply Chain Security: Integrated, Interconnected, and Context-DrivenNov 06, 2023
How to Combat the Latest Cloud Security ThreatsNov 06, 2023
Reducing Cyber Risk in Enterprise Email Systems: It's Not Just Spam and PhishingNov 01, 2023
SecOps & DevSecOps in the CloudNov 06, 2023
Passwords Are Passe: Next Gen Authentication Addresses Today's Threats
How to Deploy Zero Trust for Remote Workforce Security
What Ransomware Groups Look for in Enterprise Victims
How to Use Threat Intelligence to Mitigate Third-Party Risk
Securing the Remote Worker: How to Mitigate Off-Site Cyberattacks
9 Traits You Need to Succeed as a Cybersecurity Leader
The Ultimate Guide to the CISSP
Modernize your Security Operations with Human-Machine Intelligence
The Evolving Ransomware Threat: What Business Leaders Should Know About Data Leakage
2021 Banking and Financial Services Industry Cyber Threat Landscape Report