191–200 of 236 posts
So uh. This works on a few websites. A couple I've found http://dig.whois.com.au/dig.php?dom=jamiehankins.co.uk&type=... http://mxtoolbox.com/SuperTool.aspx?action=txt:jamiehankins....
Could anyone tell me what's about? I just see a DNS page.
Earlier quoted context omitted.
> Never trust user input. Never trust any input. I think this is a case where people assume that is isn't pure user input because is would have already been parsed/checked/verified. "Oh, its in the DNS system so it must be safe" is worse then "well, it came from our database so it should be fine". Don't even trust something coming out of your own database. You never know what various input checking bugs might have ac…
In addition to "never trust user input"; Never trust your program's output You should have two sets of sanitization, one that sanitizes incoming data, and one that sanitizes outgoing data.
So uh. This works on a few websites. A couple I've found http://dig.whois.com.au/dig.php?dom=jamiehankins.co.uk&type=... http://mxtoolbox.com/SuperTool.aspx?action=txt:jamiehankins....
Am I the only one here that doesn't get what I should be looking for? I see the txt fields have google-site-verification and peniscorp but what is that doing?
In playing around with this hack, I discovered that Dreamhost doesn't properly escape TXT records in their admin interface when modifying DNS records. I put an iframe in and it shows the box but the src is removed; it also killed the page at that point so I'm unable to remove it...
Earlier quoted context omitted.
> I am half serious Good. Still, it needs to be pointed out. This idea is an awesome hack to show how can you piggyback on existing infrastructure to make it work as something it was not intended to. But it absolutely, terribly sucks at anything practical. Actually, it's a non-solution . Here's why. > There are way fewer network round trips: > 1. DNS query for TXT record for example.com > 2. DNS reply with HTML conte…
> Both of them require you to do exactly the same steps - that is, connect to a hardcoded port of a server at a hardcoded IP address, request a user-defined resource, receive and display reply. DNS is not magic, IP addresses of DNS servers are hardcoded in your network configuration and/or in your router configuration and/or in your ISP configuration. The steps are not exactly the same. Any sensible ISP give you at l…
I am half serious, but how about making HTML served in TXT records a standard trick for serving small web pages very quickly? There are way fewer network round trips: 1. DNS query for TXT record for example.com 2. DNS reply with HTML content Compared with the traditional 7 steps: 1. DNS query for A record for example.com 2. DNS reply with x.x.x.x 3. TCP SYN to port 80 4. TCP SYN/ACK 5. TCP ACK 6. HTTP GET 7. HTTP rep…
> I am half serious Good. Still, it needs to be pointed out. This idea is an awesome hack to show how can you piggyback on existing infrastructure to make it work as something it was not intended to. But it absolutely, terribly sucks at anything practical. Actually, it's a non-solution . Here's why. > There are way fewer network round trips: > 1. DNS query for TXT record for example.com > 2. DNS reply with HTML conte…
Earlier quoted context omitted.
You are incorrect. An HTTP GET still requires a 3-way TCP handshake, so your suggestion requires 5 steps not 2: 1. TCP SYN to port 80 2. TCP SYN/ACK 3. TCP ACK 4. HTTP GET 5. HTTP reply with HTML content
FYI both a TCP SYN and SYN/ACK can carry a payload (which could be the GET and RESPONSE)
Clever. I didn't get it at first. Never trust user input. Edit: See http://www.dnswatch.info/dns/dnslookup?la=en&host=jamiehanki... for the actual code.