Live data from Hacker News

TXT Record XSS

who.is

151–160 of 236 posts

Re: TXT Record XSS

#151
post #73

Earlier quoted context omitted.

Ah yes. The occasional click to confirm this or whitelist that, that's definitively "living hell". It's the users' resistance to the slightest inconvenience that makes security so hard.

It's really a hell. Average website over there is using at least 3 - 4 external domains for css, js, fonts and so. Getting a working website without nearly whitelisting many of them is highly improbable right now.

It isn't generally that bad and if something wants 25 separate route tld's I often browse away.

Re: TXT Record XSS

#152

Earlier quoted context omitted.

For another fantastic abuse of DNS, the Iodine* project uses DNS to tunnel IP which is just obscene. http://code.kryo.se/iodine/ (Why? Lots of captive portal wifi hotspots (think hotel/train etc) seem to allow DNS resolutions before stopping your other traffic.) * DNS uses port 53 which is the same as the atomic number for Iodine ;)

Woah, awesome. I've used the http://dnstunnel.de/ tunneling scripts before, and they're a bit of a pain to setup (mostly because of the perl library requirements).

I remember using these scripts years ago when wifi hotspots used to charge obscene amounts of money...

Re: TXT Record XSS

#153
post #57

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 content

Let me show an exactly equivalent alternative implementation of the above concept.

    1. HTTP GET x.x.x.x/example
    2. HTTP reply with HTML content
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.

I know you're half-serious with this idea, but I'm going to play along. So to continue with the interesting thought experiment... if people were to start actually using DNS records to smuggle websites, they'd quickly overwhelm the capabilities of the DNS network, so the reliability and free hosting would quicky go out of window, along with all hope of ever having anything even resembling consistency in the Internet.

So yeah; a nice hack, but kids, don't try to deploy it at scale ;).

Re: TXT Record XSS

#154

Earlier quoted context omitted.

I don't think this has to do with multiprocess. The instance of HTML engine (geckk?) just needs to track who used the audio API.

I think the problem with that is it doesn't work with Flash audio. With multiprocess browsers, the Flash audio can be associated with a tab, but that's awkward/not possible if everything is in the same process.

Well, Chrome still often shares the same process for groups of tabs. I think this particular feature has something more to do with a change they made to their plugin API.

Re: TXT Record XSS

#156

Earlier quoted context omitted.

I usually just spoof mac addresses of people who already paid in most of those cases, the caveat usually being somebody had to pay.

I hope you're not still talking cruise ships here! Those folks are often paying high prices by the minute or by the megabyte for access: you'd be pretty literally stealing from your neighbors in that situation. (The moral issue for pay-by-the-day systems is one step further removed, but I think it's still real.)

802.1x covers access control to networks. MAC addresses are not for access control.

Not that a court would agree with my logic, of course.

Re: TXT Record XSS

#157

Earlier quoted context omitted.

I think the rise of no-fixed-IP load balancers like Amazon ELB has dramatically reduced that.

Aren't the IPs of the load balancers more or less fixed, though?

Using a PaaS like Elastic Beanstalk will mean a new load balancer on each publish, and those can happen multiple times per hour in a busy day.

Re: TXT Record XSS

#158
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...

Re: TXT Record XSS

#159

I added FartScroll.js from the Onion to my text records: http://dig.whois.com.au/dig.php?dom=philipithomas.com&type=A...

Notice at the bottom of that page it says:

  Embed a live DIG result (do a diggle): 
  
Now, if you embed a 'diggle', that sound like an infinite loop possibility. Interesting, does anyone want to try it?

Re: TXT Record XSS

#160

I added FartScroll.js from the Onion to my text records: http://dig.whois.com.au/dig.php?dom=philipithomas.com&type=A...

Wow, I think they fixed that escaping problem a few minutes ago.
Post reply on HN