2

There is a lot of potentially malicious stuff on the web. In fact, there are so many things that can happen that browsing to a location you know nothing about can be dangerous, like http://www.example.com/nasty.html

There may be scripts on the page, and a thousand other things. In essence, I may have forgotten to block everything.

I wonder, is it essentially free of risk to instead using wget from my terminal, like this:

wget "http://www.example.com/nasty.html"

And after that opening the file in a text editor? My understanding is that nothing then have a chance to load, but my knowledge here is blurry. Perhaps the server can trick my wget request? Or perhaps opening the file in a text editor is not a safe thing to do? I do not know, so therefore I am asking.

5
  • 2
    Another thing you maybe want to take a look at it Lynx. A text-based browser. Secure regarding malicious scripts, because it doesn't support Javascript.
    – O'Niel
    Commented Jul 24, 2016 at 14:05
  • Just announced a few weeks ago: cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4971 . Commented Jul 25, 2016 at 3:16
  • its a lot simpler to just turn off JavaScript and all the risky addons.
    – dandavis
    Commented Jul 25, 2016 at 15:24
  • @dandavis To do that, you have to know everything that can be risky. Commented Jul 25, 2016 at 15:32
  • @Hohmannfan: flash, silverlight, pdf, office are the big vectors, but you can disable them all. Its also more real-world useful to use a VM or a bootable thumb drive and "let er rip"
    – dandavis
    Commented Jul 25, 2016 at 15:46

2 Answers 2

3

You are basically correct with a couple bits of complexity.

First, it is still possible that both wget or your text editor might have a vulnerability that the page could be designed to try and exploit. This is unlikely, and the malware author would have to predict that you would use this process and plant an ambush. Unlikely, but it still means that your process is not 100% fool-proof. Just something to keep in mind.

Second, it is possible for the webserver to identify that you are using wget, and serve you a non-nasty version of the file. This is quite easily done, with examples out there, by inspecting the user-agent. Again, this is not something that malicious actors think about, but it also means that you can't use wget and assume that the file you analyse will be the file you receive in your browser.

Yes, there are ways to modify wget's user-agent to lower this possibility, but, it's still something to think about.

So, yes, you are basically correct, but it is not a silver-bullet to secure yourself, and some risks remain.

5
  • So I should use something like wget -U "<fake user-agent>" "<URL>", and even though I am still not invincible, it is better than a browser? Commented Jul 24, 2016 at 13:44
  • Using -U will help make sure that you get a consistent page, but I am unsure how effective that is. But, yeah, better than a browser. As a side note, have you heard of the Lynx browser? It's a text-based browser that splits the difference between a graphical browser and reading the source code.
    – schroeder
    Commented Jul 24, 2016 at 14:03
  • 3
    Ah, Lynx, the look-up-how-to-fix-your-graphical-desktop-when-you-break-it browser :) Commented Jul 24, 2016 at 14:06
  • Fingerprinting the user-agent and sending different content based on it isn't actually that uncommon. There are exploit kits which only serve exploits which work on the identified user-agent. When the client has a user-agent for which no exploits are available, they get a clean website (or a website with all available exploits hoping one will stick).
    – Philipp
    Commented Jul 24, 2016 at 15:24
  • @Philipp yep - not common at all, but easy to do.
    – schroeder
    Commented Jul 25, 2016 at 14:08
1

I can think of three caveats.

1) Make sure the uploaded files dont end up somewhere where they can be executed. (eg your web server folder) Otherwise scripts (for example php) can be uploaded and called/executed through the web server.

2) Continuing on this line of thinking, I think the webserver MAY dictate the filename if not set explicitly by wget. Thus allowing the source to give the file an extention such as .php

3) You might be fed a file so big, you might run out of resources (disk space, data plan), that it brings your server down.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .