Purely a guess, but I've sometimes been able to work backwards from the content length (very often included in HTTP server logs) to figure out what the body had to be.
Also keep in mind that if you use IP-based whitelisting, an attacker can register their own CF/Fastly account and target your origin server with whatever CDN settings they want (assuming they can discover your origin server). With Fastly at least you can even do this from the free tier.
Took me a second to wrap my head around what you were saying, so I'll point it out: they'd be pointing their CDN account to your origin server, and making requests through it.
This is a somewhat dangerous pattern for picking temporary files (from #8):
$ NEWFILE=/tmp/newfile_${RANDOM}
$ touch $NEWFILE
The problem is that any user on the box can create files under /tmp. An attacker can set up a bunch of symlinks like /tmp/newfile_1, ..., /tmp/newfile_99999 pointing to a file owned by your user. When your script then writes into this temporary file, you'll write through the symlink and clobber one of your own files. Especially dangerous if root :)
This has been a historic source of software vulnerabilities (often with the PID used instead as the guessable component instead of random, though). One recommended alternative is to use the `mktemp` command instead.
> As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs (cf. Listing 2).
With that said, I've personally packaged a simple backport of Python 3.6 (currently 3.6.2) for Debian stretch. There are pre-built Debian packages available in the releases tab, and a one-liner in the README for how to build them yourself: https://github.com/chriskuehl/python3.6-debian-stretch
You can install these alongside the regular python3.5 installation (it doesn't replace it).
I haven't tried it yet. I remember seeing that comment from Chris Lamb but I'm left wondering what the blockers are to getting 3.6 in backports. I messed around with another python3.6 deb (don't remember from where) and there were too many issues with it; namely with venvs.
I've been using my packaged version pretty extensively (mostly in virtualenvs) and haven't encountered any issues yet myself, but would definitely be interested to hear (either on GitHub or here) what issues you encountered and if they occur with my packaged version as well.
I wouldn't really expect any issues since it doesn't replace `/usr/bin/python3` (it just adds a `/usr/bin/python3.6`), but it's definitely possible I just haven't run into them.
IIRC, the python3.6 from testing was causing inconsistencies in the /lib packages shipped inside the virtualenv (like inconsistent versions would get imported). I'll definitely give your package a shot!
A benefit of installing using your system package manager is that you can rely on your distro to manage the security of the package. If you just `pip install` it, you need to personally watch for new security bugs and upgrade (or backport them to your current version, which is what e.g. Debian will do for you). You'd also need to do that for all of the dependencies.
Up to you if you trust your distro's security team, of course :). I trust mine.
I did not say anything about package managers. I trust my distro and its suppplied packages just like you trust yours and aim to use official packages as much as I can.
The instructions in README.md say "sudo pip install" and "sudo ./setup.py". To me, that is a bad idea. Things that are manually installed should be kept in completely separate directories. My preference is to install such packages in my home directory, which should in no way require sudo.
Totally agreed they have the right to monitor your network traffic, but I still think in most cases employees should try to push back on this.
At least from my view, it's not so much that I don't want my company to know what I'm doing, as that I don't trust their software to securely MITM all of my traffic. This thread doesn't fill me with confidence about the competency of these corporate MITM proxies. And the recent Cloudflare news doesn't help either -- they're effectively the world's largest MITM proxy, and even they couldn't avoid leaking a huge amount of "secure" traffic.
There are surely sectors where it's necessary for a company to MITM all traffic, but I think most companies will do better security-wise by not messing with TLS. It's just too hard to get right.
At my workplace where we have to do tls inspection for regulatory purposes we provide an internet-only wifi network for employee personal use where we don't intercept TLS. This network is fully isolated from the corporate network and corporate devices join a different, more monitored network. I believe this strikes the best balance between regulatory compliance and employee privacy. People can still use personal email or do online banking while at the office without inspection, but no corporate data can be moved en mass off company servers.
When connecting a corporate device to any non-corporate network (including the employee wifi) you can't go anywhere until the vpn is connected. The vpn routes you through all the same inspection points as being on premise.
And how can your inspection points verify that data isn't being exfiltrated? Arbitrary pipes can be made over SSH, over DNS, and I don't really consider these advanced. How do you handle techniques like chaffing and winnowing, steganography, or someone who knows how to transmit an arbitrary number of bits using only two bits?
DNS is my favourite hack in that respect because so few people are aware of it.
For those who don't know, there are even full IP proxies that uses DNS [1], but you can hack up a primitive one using shell script by basically setting up a nameserver for a domain, turning on all query logging and using a shell script that splits your file up, encodes it into valid DNS labels and requests [some encoded segment].[yourdomain]. Now your file will be sitting in pieces in your DNS query log and all you need is a simple script to re-assemble it.
Best of all is that it works even if it passes through intermediary DNS servers, such as a corporate proxy, unless it's heavily filtered (e.g. whitelisting domains) or too rate limited to be useful.
The VPN clients offer a "hotspot login" or such functionality so that you can open the access. It doesn't work for other use, just opening that VPN so that your company computer can connect to company network.
That obvious workaround doesn't give you a 24/7 hole from the Internet. To copy information, you need a person to knowingly do it. This decreases the attack surface tremendously.
