Hey /prog/, not a regular but I thought I'd try you guys - I'm running into problems when I try to load cross-board content using xmlhttprequest. Apparently it only works in the same domain, so I get security errors when a link pointing to img wants to load content from dat (the cross-board links send you to a redirecting page which does this). Any ideas on how to work through this? I'm running the code through the Greasemonkey Firefox extension. Thanks!
Hey, thanks everyone! I told /pr/ that I started reading SICP, but for some reason they banned my IP for 12 years -_-. Oh well, I can just ask you guys anyway right? :)
You can modify Firefox' settings to enable cross-domain XHR (prefs.js I guess?). However, you would have to convince others to do so as well to use your script, and I'd like to see the gullibledumb fuck who would. You're opening up your browser for a wide range of XSS exploits by doing so, after all.
Name:
Anonymous2009-03-19 18:56
>>12 opening up your browser for a wide range of XSS exploits by doing so
I don't think so.
Give a few examples?
Name:
Anonymous2009-03-19 19:07
Do you even know how XMLHttpRequest works? Imagine a script which reads a password input element and sends this asynchronously to the villian's web server.
>>14
Imagine a script which reads a password and sends this anywhere. I hope I never have to use any web app you wrote.
Name:
Anonymous2009-03-19 20:10
>>14
...Do you even know how the internet works? Anyone who is using a plaintext password input is going to be insecure anyway. And the fuck anyway- for your scenario to happen the user needs to run a malicious script on that page; or the server needs to have been compromised in which case whether or not they are using AJAX to remotely deliver posted passwords has no effect whatsoever on the insecurity.
>>20
So…you embed a bare socket terminal in the web page and force the user to compute and type out SSL packets? Classy.
Name:
Anonymous2009-03-19 20:51
>>20
SSL is irrelevant because we're assuming the victim is using somebody's malicious UserJS/GreaseMonkey script, where it can pick up your password when it is in plaintext on the client-side.
The attack model is as such:
1) Villian has written UserJS script which makes use of XHR
2) Victim has Cross-site XHR enabled
3) Victim is using villian's UserJS script
At this moment, it is quite trivial for the Villian's UserJS to use some sort of timer/event handler to pick up the password at an arbitrary moment before it is sent over the wire, ie. onsubmit event handler. When you have the password, you can utilize XHR to send the contents to your own server, which normally would not be allowed since by default cross-site xhr is disabled.
Name:
Anonymous2009-03-19 21:15
>>19
Client-side hashing and cryptographic nonces. There is absolutely no reason passwords have to travel over the network.
Ask Xarn, he knows about crypto.[1]
>>24
We're talking about input from the user to a web app, so yes, we are. The fact that you thought you were being clever by talking about HTML form input fields isn't particularly relevant.
(And wrong even if it were; by hashing the input to a certain form field, it becomes an encrypted field. The fact that it happens through Javascript instead of some mechanic in the HTML parser in the browser is unimportant.)
Name:
Anonymous2009-03-19 21:32
>>22
You can't protect users from themselves. If they are stupid enough to run a mallicious script; so be it. The internet and the standards/protocols it relies on shouldn't be wrapped up in plastic and coated in chocolate for the kiddies to be able to play. It needs to be advanced and improved every day to facilitate human advancement; without giving a shit what some dumbass might do to himself if he tries to use it.
>>26
Don't pretend you have the time to fully audit the source of every little application you use. Defense in depth is a good thing either way you look at it.
Name:
Anonymous2009-03-19 21:42
>>27 Don't pretend you have the time to fully audit the source of every little application you use.
No, I god damn well don't. You know what does? My CPU, and in a theoretical sense Anti Virus program. Restricting cross-site XHR would be akin to an operating flat out restricting any program from accessing the network (because they could be mallicious right?) And only via a user going into their registry can they actually allow programs to access their network. Browsers in their ongoing war of bullshit "tight security" and "robustness" have gone too far and are actually taking away usability. The only reason this stands is because there is no mechanism to change it- developers can't make websites/services that rely on cross-site XHR because nobody has it enabled. They make shitty hacks and workarounds, and we all have a worse experience (except the eight year old down the road who avoided losing his something awful account).
Name:
Anonymous2009-03-19 21:56
I'm running the code through the Greasemonkey Firefox extension
Just use GM_xmlhttpRequest, it can make requests to any domain. Way to fail at answering a simple question, /prog/.
>>28 My CPU, and in a theoretical sense Anti Virus program.
Oh wow. Sorry, for a moment I thought I was talking to someone who had a clue about anything but was just a bit confused.
>>31
Great way to come out trumps in potentially serious discus... oh... wait.
Name:
Anonymous2009-03-19 22:37
>>28
If you want to screw with him, allow him through for a while. Set up a computer between the router and the internet connection, with a bridged network, sniffing the traffic. Put Ettercap into promiscuous mode, set up a log file. After you've let the offending user access the internet for a suitable period of time, run etterlog -p <logfile>. This will automatically scour the log file for login information (only works with insecure connections, like http).
For added kicks, get Ettercap to filter https in the url's and replace it http, which should get you login information if the user attempts to login to a secure site that also is accessible through http. May tip them off to something being wrong, as it will also basically deny access to secure sites that do not have insecure connections.
>>25
No, you ignorant bastard. This is an issue of malicious javascript stealing the text from a form input. Transmission protocols don't factor into it one bit.
>>34
It could be interpreted either way, the original comment reads: Anyone who is using a plaintext password input is going to be insecure anyway
This could imply either that they are insecure because a plaintext password is being sent over a network, or because a plaintext password is entered and stored in the input field.
Name:
Anonymous2009-03-20 5:11
>>35
Or you could just take the comment at face value and read it as meaning anyone who uses plaintext passwords also lacks self-confidence or a personal feeling of safety.
Name:
Anonymous2009-03-20 5:58
>>29
Thanks, I found that pretty soon after making this thread actually. Feel free to continue discussing malicious javascript, /prog/.
You faggots. This shit was already solved ages ago. What you need is a public+private key system, using a smart card, were the private key never leaves the card.
Anything else are band aids. HTTPS is fucking useless in the real world, who sniffs networks for real? Maybe in public places (<0.1% of total users), but at home 99.9999% of information thefts are a result of the machine being compromised. Good luck with that!