Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: .com. filter bypass |
|---|---|
| Date: | Thu, 19 Aug 2004 10:04:14 -0400 (EDT) |
I know this is pretty trivial, but I haven't seen anyone write anything about this. I'm not sure how useful it really is as an attack vector, but: "http://www.google.com./" is a valid url in browsers (with the dot at the end). It seems like it might be used to circumvent some pattern matching filters in use with CGIs. Something like: #!/usr/bin/perl print "Content-Type: text/html\n\n"; $domain_query = $ENV{QUERY_STRING} # $domain_query is "www.google.com." if ($domain_query !~ m/^www\.google\.com$/){ #execute something you normally wouldn't allow for www.google.com } else { print "Sorry!\n"; }
On 13 October 2003, Richard M. Smith posted a like report to the bugtraq list referring to an issue within IE and cookies. I would provide a link but the securityfocus.com site is really, really slow right now. If you can get to it, I think it's a pretty good read, although maybe not necessarily relevant from a CGI/web application perspective.
Where the URL in this case actually is google.com when rendered. I tested this with IE on XP Pro and lynx on XP Pro cygwin and on FBSD. As a side note, nslookup and traceroute both ignored the trailing period, which actually is okay behavior, but also makes them candidates if this sort of check is performed before they are run with a system call.... Yup, as I said, pretty trivial.
The behavior for nslookup and other DNS resolvers is to be expected if and only if the default domains you search do not have an entry that matches the host. If your resolver's domain list defines 'securityfocus.com' as a default domain, google.com and google.com. will be handled identical as long as there is no DNS entry for google.com.securityfocus.com. The importance of the period at the end of the host is that it ensures that the host is handled as if its last domain part, i.e. 'com' is handled from the DNS root rather than from a more local area. This behavior is seen in BIND configuration files where missing the final '.' results in adding the domain name to the end of the host. (I would guess it's one of the most common DNS configuration problems.) Most people, including programmers and anyone who is either not familiar with BIND (I do not know if djbdns or other DNS servers suffer as readily from this issue) or the RFCs pertaining to DNS, are blissfully unaware of the trailing dot and its relevance or purpose in DNS. (You don't see people advertising the URL for their site as "http://www.mysite.com.", do you?) As a result, you see issues in code like the filter you present above. I don't think this sort of issue is mentioned in any texts on domain/host matching (although I admittedly have not read many on the subject). Sincerely, Chris Ess System Administrator / CDTT (Certified Duct Tape Technician)
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | IE cookie menagment and CSRF, lazy |
|---|---|
| Next by Date: | Re: ArtistScope, Denis Pankratov |
| Previous by Thread: | Re: .com. filter bypass, Martin Mačok |
| Next by Thread: | Re: .com. filter bypass, Nigel Stepp |
| Indexes: | [Date] [Thread] [Top] [All Lists] |