Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TXT Record XSS

who.is

Post reply on HN
Print view View original

221–230 of 236 posts

Re: TXT Record XSS

#221

Post by dspillett »

arenaninja wrote: post #21
dspillett wrote: post #6

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…

This is only too true! At work we do CRUD projects, which means user input gets stored in the database. I almost always break other people's work by adding HTML tags to the inputs, navigating back to the page, and seeing markup that shouldn't be there. Even database output needs to be sanitized

Same here. It is surprising how many times I've done that over the years and people are both surprised how easy it was but easily convince themselves that "it'll be all right" somehow and they'll fix it later...

Re: TXT Record XSS

#222

Post by dspillett »

billmalarky wrote: post #194
bsamuels wrote: post #36

Earlier quoted context omitted.

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.

I disagree. Obviously data should be validated. But passing validation, I prefer to store data exactly as the user supplied it and then sanitize on output. That way you always have a copy of the original data assuming things change.

Definitely. If it is genuinely invalid, refuse it, otherwise store everything as-is. You don't know on the way in what encoding will be needed on the way out: the same sting could be output later plain, in HTML, in a JS literal, in SQL if someone is daft enough to use ad-hoc unparamerterised queries, and so forth.

Re: TXT Record XSS

#223

Post by nhstanley »

kazinator wrote: post #114

Since there is very little discussion in the link, pardon me for stating what may be obvious to some, but not necessarily everyone. The point here is that: 1. DNS TXT records can contain HTML, including scripts and whatever. 2. Domain registrants can publish arbitrary TXT records. 3. TXT records can appear in pages generated by web sites which serve, for instance, as portals for viewing domain registration informatio…

Thanks for explaining. I know HN is traditionally programmer/programming focused, but some of us come from other areas and only have limited experience with such topics. It's very common for me to enter a thread about a security vulnerability, for example, and think "wait, how big of a deal is this?"

Re: TXT Record XSS

#224

Post by ceejayoz »

AnthonyMouse wrote: post #215
WiseWeasel wrote: post #187

Earlier quoted context omitted.

Yeah, you might have a tough time explaining to the judge that Media Access Control addresses are not for access control.

In this context "access control" doesn't mean what you think it does. It refers to multiplexing the communications of multiple devices over a single shared communications medium, as in "controlling" (arbitrating) shared access to the radio spectrum. It has no relationship to network authorization or authentication and provides no security whatsoever. http://en.wikipedia.org/wiki/Channel_access_method Calling it "acce…

> In this context "access control" doesn't mean what you think it does.

Good luck explaining that to the judge.

Re: TXT Record XSS

#225

Post by growupkids »

AnthonyMouse wrote: post #215
WiseWeasel wrote: post #187

Earlier quoted context omitted.

Yeah, you might have a tough time explaining to the judge that Media Access Control addresses are not for access control.

In this context "access control" doesn't mean what you think it does. It refers to multiplexing the communications of multiple devices over a single shared communications medium, as in "controlling" (arbitrating) shared access to the radio spectrum. It has no relationship to network authorization or authentication and provides no security whatsoever. http://en.wikipedia.org/wiki/Channel_access_method Calling it "acce…

Regardless, the judge is going to look at intent and knowledge. You knew this was a paid service, and your intent was to not pay. You understood this was a way to avoid payment, and you understood that someone else had paid for access.

Re: TXT Record XSS

#226

Post by vdm »

mrb wrote: 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…

Van Jacobsen's NDN (née CCNX) does this by replacing the entire HTTP to IP stack with a hierarchical key-value protocol using only two packet types: Interest (GET) and Data (PUT). It can overlay UDP or any layer 2 directly, and tunnel IP. http://named-data.net/

Re: TXT Record XSS

#228

Post by peterwwillis »

zackb wrote: post #162
TeMPOraL wrote: post #153

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…

I think his point is that DNS doesn't require the TCP or HTTP overhead. There are more steps and layers involved with an HTTP GET and reply than with DNS resolution.

It requires TCP overhead if the dns packet is bigger than 512 bytes. You could abuse the DNS protocol to carry HTTP-esque metadata but it would be a small victory over standard HTTP. Reusing an existing TCP connection is more efficient.

Re: TXT Record XSS

#229

Post by AnthonyMouse »

growupkids wrote: post #225
AnthonyMouse wrote: post #215

Earlier quoted context omitted.

In this context "access control" doesn't mean what you think it does. It refers to multiplexing the communications of multiple devices over a single shared communications medium, as in "controlling" (arbitrating) shared access to the radio spectrum. It has no relationship to network authorization or authentication and provides no security whatsoever. http://en.wikipedia.org/wiki/Channel_access_method Calling it "acce…

Regardless, the judge is going to look at intent and knowledge. You knew this was a paid service, and your intent was to not pay. You understood this was a way to avoid payment, and you understood that someone else had paid for access.

None of which has anything to do with "media access control" which still has nothing to do with authorization or authentication.

Re: TXT Record XSS

#230

Post by peterwwillis »

venaoy wrote: post #174
callesgg wrote: post #172

Earlier quoted context omitted.

A UDP dns response will be truncated if it is longer than 512 bytes. If you want more stuff you have to use TCP and that is not very preferable.

False. IP fragmentation allows the size of a single UDP DNS response to be up to 65535 bytes, regardless of the network MTU.

The great majority of networks out in the world discard UDP DNS packets bigger than 512 bytes. Firewall admins do it, DNS admins do it, application proxies do it, birds do it, bees do it, even educated fleas do it....

As far as the 65535 limit, from RFC 2671:

  4.5.5. Due to transaction overhead, it is unwise to advertise an
       architectural limit as a maximum UDP payload size.  Just because
       your stack can reassemble 64KB datagrams, don't assume that you
       want to spend more than about 4KB of state memory per ongoing
       transaction.
Post reply on HN