TXT Record XSS • Hacker News Board

UweSchmidt wrote: post #52

TallboyOne wrote: post #46

Earlier quoted context omitted.

For making your life living hell in the name of overbearing security measures.

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.

Re: TXT Record XSS

#74

Post by bdpuk » Thu, Sep 18, 2014, 6:27 PM UTC

I've seen similar examples with HTTP headers and sites that display those, nice angle.

Re: TXT Record XSS

#75

Post by swartkrans » Thu, Sep 18, 2014, 6:29 PM UTC

JamieH wrote: post #4

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

So like, what template library are these sites using that doesn't have basic XSS protection. :|

Re: TXT Record XSS

#76

Post by [deleted] » Thu, Sep 18, 2014, 6:29 PM UTC

[deleted]

Re: TXT Record XSS

#77

Post by ashearer » Thu, Sep 18, 2014, 6:30 PM UTC

dspillett wrote: post #6

rbinv wrote: post #3

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.

> 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…

Thinking about it as "don't concatenate different data types" leads to even more correct software. Concepts like "trust" and "sanitization" are too often vague and misleading. It might be perfectly valid for TXT records--even trusted and sanitized ones--to contain sequences with left angle brackets that make them look like HTML tags. Either way, that's no excuse for failing to convert the text to HTML (by escaping it) before concatenating it into an HTML page.

Re: TXT Record XSS

#78

Post by 0x0 » Thu, Sep 18, 2014, 6:30 PM UTC

_RPM wrote: post #65

wittrock wrote: post #60

Earlier quoted context omitted.

That's the point--who.is won't play music by itself. Its lookup of the DNS records of jaimehawkins.co.uk injected the music into the page.

Oh I see. This makes sense. This doesn't seem challenging to prevent. A simple replacement of characters on the HTML entity table would have prevented this instead of putting arbitrary text onto standard output.

Yep, missing that is what makes this an "XSS" :)

Re: TXT Record XSS

#79

Post by 0x0 » Thu, Sep 18, 2014, 6:31 PM UTC

jcromartie wrote: post #72

r0m4n0 wrote: post #16

isn't this technically illegal to demonstrate haha?

Those DNS lookup sites are pulling his information and putting it on their sites. He didn't ask for those records to be published!

Ah, so his TXT records actually serve a genuine purpose? ;)

Re: TXT Record XSS

#80

Post by ryan-c » Thu, Sep 18, 2014, 6:31 PM UTC

apetresc wrote: post #44

ryan-c wrote: post #34

I enumerated all IPv4 PTR records a few years back, and I saw a couple XSS things there as well. If anyone wants to host that data set somewhere, let me know, would be interesting to see what others do with it. Edit: I found my data and have a grep running on it, will share what turns up. Edit2: Somewhat less exciting than I remember: $ fgrep -- '>' * x.x.101.130.csv:1298607746,155.92.101.130, .nebula.msoe.edu. x.x.1…

How large is it, ballpark?

It's about 3.5GB compressed, though in addition to un-LZMAing it a custom unpacker consisting of a few dozen lines of perl is required.