nCircle VERT Blog

This is simple to figure out -- where is the attacker? The attacker's perspective is the only things that matters in matters of local vs. remote.

While I can appreciate your definitions for local and remote, I think the classifications are too broad. I am reticent to call this a taxonomy of attack sources/targets, but it seems needful as the simple local and remote distinctions lack the precision to prevent overlap. Any good classification system should attempt to resist this problem. I know, it is rarely, if ever, achievable. Adding additional criteria will, I think, take the 'justification process' out of the equation when attempting to classify vulnerability sources/targets. If certain classes of vulnerabilities require this justification of placement/selection then it is a good indicator that our classification mechanism is a bit too broad.

This is a goofy discussion. Nonetheless, I'll engage.

It's a local exploit class. I take this point of view because XSS does NOT run in the context of the remote system like say, SQL injection. The execution is always on the client - it does not affect the server system (sans some other vulnerability allowing this).

Note that I'll take this point of view for "stored" XSS vulnerabilities too. Just because something is "stored" on a "remote" system does not mean it affects that remote system as an attack.

The bottom line is that the victim is generally on the CLIENT side, running in the context of a LOCAL web browser. If you take the client out of the question, what threat is XSS?

byeee!!!!!!!!

@roodee:

I agree that the classification method is broad, however I'm not sure that being too broad is a problem... eventually everything needs to be boiled down into a minimum level of classification.

@lordm:

I question why you see it as a goofy discussion. You are arguing that the execution happens on the client so it's a local attack. Consider this:

The attack on the client is a secondary to the Injection attack that was performed against the server. Since the Injection attack is the primary attack and it affects the server that makes it a remote attack.

I can definitely understand the debate between whether it is a remote or local issue. I called it goofy because with respect to what really matters in security, this might not be the highest priority discussion. Anyway, I'm interested in this topic, so sorry for the poor choice of words.

My original thought was "it's a local exploit if it RUNS locally." I thought, "How does an XSS attack 'affect' the server? It runs on the client." Sure, it might be stored (e.g. persistent attacks) on the server, but it does not affect the operation of the server system. Without the client (browser, etc.) to carry it out, an XSS "exploit" is as harmless as any other arrangement of characters.

That being stated, I have a new perspective. While the XSS does run LOCALLY to a victim, it does not run locally to the attacker. The exploit actually runs on the victim's browser. In this respect, I consider this a remote exploit.

The real remote factor here is that the attack carries out on another host. I'll never concede that its a remote exploit simply because the web app has a vulnerability that allows it to be stored, since the remote system _affected_ here is NOT the web server, but the remote client who gets owned.

Finally, I must throw in this one disclaimer. I'm not completely sold on my perspective. It might be wrong, and I might change it. I'm just trying to reach a conclusion from having thought about it. Thank you for your time.

Shoot over an email if you'd prefer to continue this offline.

It's all academic really - in real life the classification systems fall short. While
'remote' vs 'local' is handy, it's not entirely accurate... it takes two to tango.

First and foremost, in my mind, to deciding the nature of 'remote' vs 'local' is where interpretation takes place. Just because someone, at a distance and by whatever means, inserts something means nothing. Code is nothing, just symbols, and certainly not any kind of turing complete entity.

Saying the nature of XSS is remote is like saying a book is dangerous... no, it's not, they do nothing by themselves, it's the people manipulating them, INTERPRETING them, that bring danger into the equation.

To continue the book metaphor, it does not become 'remote' just because you busted into a bookstore and added something to a book that hoping someone would buy it the next day and do something stupid.

Again, XSS just sitting there does nothing, it requires an active party. That active party is the client.

XSS, all technical intricacies aside, should probably be treated like trojans are treated. It's the same thing really, stuff pretending to be other stuff that require the victim to retrieve the payload and activate it on their local machine.

The injection is NOT the primary attack though it may be the first stage. The primary goal is to get someone, the client, to do something against their best interests. After all, that's what you're defending against.

It should not be up to the server to have to sanitize input, especially if by not sanitizing input the server brings no harm on itself.

Calling this remote also provides a convenient cover for the lazy browser and client manufacturers... "Hey, it's not us, it's the evil server sending us XSS!". Nonsense.

It's lazy and misguided to assume, and place, responsibility on the server for judging the 'evil' or 'goodness' of code (as if it could!) and then enforce it arbitrarily by not allowing certain characters or sequences. Maybe you want to be able to enter and manipulate that.

No, the real problem is here is lazy client software and browsers caused by business jumping on the internet bandwagon without properly understanding it's technical nature. And promising security where than can inherently be none.

Interesting topic, here's my $0.02

XSS is fundamentally a local exploit, therefore it's a local vuln. Sure it's remote to the attacker; but who are we trying to protect? All vuln assessment should be taken from the victim perspective.

XSS requires user initiation without that, the exploit goes un-used. The protections for XSS will also always be required on the client side. It's impossible eradicate all XSS vulns.

The assertion that the "trust relationship between the user and the web server has been violated" is only half correct. It's the trust relationship between the user and the web service that's been violated. The server is just a piece of the technology. It's the service that's been compromised from the users perspective. This is an important distinction as it also helps clarify where the protection needs to be made. The user has no ability to alter the behaviour of the remote technology (server), but DOES have the ability to use technology to protect the integrity of the service.

XSS is a tough one, since the initiation of the exploit takes place remotely, but the execution of the exploit is local. In these 50/50 scenarios is comes down to the victim perspective. It's the victims actions that "cause" the code to be executed, therefore it's local.