XSS: What Type of Vuln Is It?

Hey Hey,

This is actually from an older blog post that I wrote. To give you a small portion of the difference between Local and Remote vulns and my feelings, I'll quote part of it... but I'd appreciate it if people read the post and the comments... I think this could turn into a rather interesting discussion point...

Quote:

---

Local Vulnerability: A vulnerability affecting a client, generally you can think of this as falling into two types. Type 1 is physical access required and Type 2 is user interaction required.

Remote Vulnerability: A vulnerability affecting a remotely available service, or something available via that service.

So... Is XSS a local or a remote? I'll tell you that I'm fairly close-minded on this topic, so unless you've got a fairly compelling reason to argue it's a local, I'll most likely disagree. My answer is remote. Why? The XSS exists in a web page. The web page is hosted on a web server and is remotely available. To me that makes sense, I'm not sure that it can really be disagreed with. An argument for XSS being considered a local is that the client is affected... this seems to make sense. You visit a web page and a pop-up containing 'XSS' suddenly shows up but sit down and consider what happens.

---

Peace,
HT

Question for you. Why does it either have to be local or remote? Why can't it be both? Where is the rule laid out that it can only be one or the other?

I would say it is both local and remote. It just depends on the perspective. Are you the victim or the attacker? Or are you both?

Quote:

---

Originally Posted by phishphreek

Question for you. Why does it either have to be local or remote? Why can't it be both? Where is the rule laid out that it can only be one or the other?

I would say it is both local and remote. It just depends on the perspective. Are you the victim or the attacker? Or are you both?

---

That's an interesting question... why can't it be both... This why (in my opinion) it can't be both:

Local, Type 1: Requires Physical Access... this is immediately ruled out... Couldn't possibly be this (I'm being generic here... there's some software that never goes on the net, but renders HTML/JS and is vulnerable to XSS in this case... but I'm going to talk XSS as most people think of it... )

Local, Type 2: User interaction... You browse to a website (for example) and exploit code runs... It sure sounds right... but let's look at remote.

Remote: Affecting a remote service or something offered by that service... Well the webpage is offered by the service... and we originally attacked that... So it could be this.

So we have Local, Type 2 and Remote...

Now we have to think about XSS... What is Cross Site Scripting?? In order to be Local, Type 2... all javascript executing on a computer would have to be XSS, meaning every page in the world is serving up all types of XSS... This isn't the case (even though most pages are vulnerable)... not all javascript is instantly malicious and considered a threat...

Remote... We are bypassing / defeating filtering mechanisms to reflect or store an attack via the server.... The executed code is acceptable and valid to the client... the server shouldn't have allowed it to happen.

Since XSS is a bypassing of website filtering to store/reflect potentially malicious, yet valid, code... I still see it as remote....

After all, we're discussing creation/injection of the XSS, not the outcome of acceptable javascript execution.

Well, then I see only one thing left to do! We need a new classification. It's the natural thing to do with evolution, right? I propose we call it a "relocal" or "remocal" attack. :p

But the browsers aren't doing anything outside of what they're designed for. It's more of a flaw in web applications.

Personally I loosley clasify an attack as local or remote depening on who the target is - from an attackers prospective both the users browser and the web server are remote to him - unless he was attacking himself then it would be local - to me a local exploit means your physically logged on to the box you want to attack - and run the attack from there.

The user who is attacked runs the XSS 'script' locally - ergo IMO XSS is a local exploit.

Hmmm,

I think that the question is one of semantics? by that I mean that it depends on your definition of "local" and "remote".

What I am really asking is what constitutes "remote"........... like if the compromised server is on your LAN or even your WAN is that a remote or a local attack?

Suppose we look at the source of the infection?

1. Internet Remote.................... even that isn't clear cut, as you may use the internet to connect to a server that is within your corporate or institutional structure.
2. WAN Remote................. well it is a server and the technique is the same, isn't it?............ and "it isn't in our particular silo of corporate responsibility". :D
3. LAN............. errr? it is from a server and not restricted to the client, and the server is in another room/building, so is it remote?

I guess if a bozo brings in infected laptop or media, then that has to be local, when he synchronises or loads stuff onto his desktop.

What about an attack over the local network (peer to peer) or the WAN?

I think that we need to look at refining the definitions, as I believe that they apply to attacks in general, not just XSS

And I would say that is just the tip of the iceberg:confused:

Quote:

---

Originally Posted by The-Spec

But the browsers aren't doing anything outside of what they're designed for. It's more of a flaw in web applications.

---

This is essentially what I'm saying... the flaw exists in the web application (occasionally the web server... The Trace/Expect headers (for example) have both been known to be vulnerable to XSS)

I see the web application as being remote though... it's not usually considered a local application.

Nokia: What if the target is your home computer, and the attack is a DoS... following what you said there, I'd think you'd call it local (however I know you wouldn't)... The "XSS 'script'" as you put it is just javascript... a browser is supposed to execute that... there's no vulnerability/exploit introduced at that stage.

nihil: I would say on a LAN/WAN is still remote in the same way that the internet is... Because if you took the vulnerable web app on your LAN and placed it on the internet, the XSS would still exist...

Quote:

---

nihil: I would say on a LAN/WAN is still remote in the same way that the internet is... Because if you took the vulnerable web app on your LAN and placed it on the internet, the XSS would still exist...

---

I would agree with that, as that is how I understand the mechanism works.

The reason that I raised the point is that I know quite a few over here who seem to take the view that if the server is under their control then it is "internal" and if it isn't then it is "external"

I suspect that reflects a "blame culture" mentality? :D

Quote:

---

Originally Posted by nihil

I would agree with that, as that is how I understand the mechanism works.

The reason that I raised the point is that I know quite a few over here who seem to take the view that if the server is under their control then it is "internal" and if it isn't then it is "external"

I suspect that reflects a "blame culture" mentality? :D

---

I think that in that case "internal" and "external" apply in those cases.... However I don't think that internal/external is synonymous with local/remote.