| Author |
Thread Statistics | Show CCP posts - 12 post(s) |
Aethlyn
20
   |
Posted - 2011.09.06 13:37:00 -
[1] - Quote
Code wise it's impossible to tell if an URL points to a static image or a server side script file, making it impossible to detect the real origin of the data transmitted to the user. Some forums utilize some simple file name matching (e.g. forcing the file name to end with ".png" or ".jpg"). However this isn't any real secure solution at all as it will only block very simple attempts. It takes less than a minute to write server side code that will be requested using something like http://example.com/static_image.jpg. On the first look this might appear to be a static JPEG image. However it could be anything, it could essentially be some script retrieving the page you're looking at and rendering it to an image (or doing more nasty things like trying to peek on the page's URL and/or cookies and/or trying to exploit some browser or image filter vulnerability.
Looking for more thoughts? Read my blog or follow me on Twitter. |
Aethlyn
20
|
Posted - 2011.09.06 13:48:00 -
[2] - Quote
It didn't change - but the old forums were on http only anyway. It's more like an improvement: Why switching to HTTPS while keeping the images back door open?
Looking for more thoughts? Read my blog or follow me on Twitter. |
Aethlyn
20
|
Posted - 2011.09.06 13:56:00 -
[3] - Quote
Tippia wrote:What you're talking about is a flaw in the browser. The forum software will simply put that url into an img tag, and if the browser is so ******** as to accept (much less execute) anything other than an image file coming through that link, then that browser needs to be fixed was retired 5 years ago.
No, (despite the mentioned possible client side exploits) I'm talking about server side code that's run when the image is requested. Depending on your browser it will send quite a few lines of information, including referral information and such. It's the way classic non-JavaScript stats tracking scripts work. This not only opens up possible exploits (it's not like you need only 5 minutes and you've got something to explot - let's be honest) but also privacy issues (e.g. in Germany some instances actually want to force the removal of facebook's "I like" buttons due to them collecting data just by being embedded into the pages). I know that most abusive stuff will require at least some JavaScript code, but it's possible to get quite some data utilizing simple HTTP requests, e.g. for images.
Looking for more thoughts? Read my blog or follow me on Twitter. |
Aethlyn
20
|
Posted - 2011.09.06 14:20:00 -
[4] - Quote
Client side exploits as in buffer overflows, image filter issues, etc.
Refreshing this page without hitting the cache requests content from the following servers:
https://forums.eveonline.com/
https://gate.eveonline.com/
https://image.eveonline.com/
https://ajax.googleapis.com/
https://ssl.google-analytics.com/
These involve 2 companies but I've got complete control over this (e.g. by blocking google analytics in your browser).
But how should this work for tons of unknown image hosts? Sure, you could opt them in one by one but this wouldn't really increase your security (casual users won't see any sense behind this anyway). It just adds tons of overhead either server or client side.
Looking for more thoughts? Read my blog or follow me on Twitter. |
Aethlyn
20
|
Posted - 2011.09.06 14:41:00 -
[5] - Quote
The fact there are accounts linked to it that can be valueable in the right context, including possible online transactions (entering payment information probably on the same machine you're browsing the forum with)?
For those looking for an abusive scenario not requiring direct script access on the client machine:
- Player uses the ingame browser to read forums.
- Image is loaded from malicious site.
- This might provide more or less (depending on player's system security) valueable information to someone trying to hijack the system: a) the player is running EVE right now b) the player's IP.
- With this information there is the possibility the attacker might abuse existing vulnerabilities (screwed up NAT settings, missing firewall, whatever) to hijack specifically players of EVE instead of just trying random IPs.
This doesn't involve any information usually kept/not sent by browsers regardless of their security settings.
Looking for more thoughts? Read my blog or follow me on Twitter. |
| |
|