Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

This Week I Learned - 2016 Week 24

Last week write-up or you might want to read the whole series.

Typosquatting programming language package managers. Mostly likely inspired by the Npm's left-pad incident.

Print debugging on steroid in PHP? Try Kint.

Due to the decommission of CPU processor by big Internet companies, the used market was flooded with Xeon E5-2670. Hence, there are many who tried to build a powerful Dual-Xeon machine. While the processor is roughly around USD 70 and highly soughtable, the motherboard is very costly. It's reasonable that everyone want to assembly the most powerful machine with minimum cost. However, judging by the TDP, it recommended to build smaller and more economical home lab. Again, it still depends on what the main purpose you want to build your own home lab.

tl;dr: Maintenance code: 3008.

Have an Unifi account with the Huawei EC6108V8 media player? Want to make the most of this tiny device? The essential configuration and setup steps are in post #10, #14, #32 (enable you to login to Play Store), #69, #90, #98, #102, #103, #178 (if #32 doesn't work), #190, #208 (similar to #178), #218 (maintenance code), #252, #263, #278 (similar to #178 and #208), #287, #291, #311, #319, #359, #377 (like #178), #387 (device specification), and #414.

Breach SSL Attack

A way better write-up of BREACH SSL attack with details explanation and example. Can I safely assumed that as long as you're randomizing your Cross-site Request Forgery (CSRF) token, your web application should be safe?

Quickest Mitigation to BREACH Attack

Before that, the best explanation I read so far on BREACH attack. To quote from Wikipedia,
"A BREACH attack can extract login tokens, email addresses or other sensitive information from TLS encrypted web traffic in as little as 30 seconds (depending on the number of bytes to be extracted), provided the attacker tricks the victim into visiting a malicious web link."
Maybe is just me but way better explained that the official disclosure. Reluctantly (since performance will be affected), I've opted the most effective mitigation method by disabling HTTP-compression at server side. Example given here is running on #Apache 2.2.22 in Ubuntu 13.04.

1. Check our Apache web server version.
$ apache2 -v
Server version: Apache/2.2.22 (Ubuntu)
Server built:   Jul 12 2013 13:18:14

2. Check if the dynamic module deflate is enabled.
$ sudo apachectl -t -D DUMP_MODULES | grep deflate
 deflate_module (shared)
Syntax OK

3. Double-confirm that the web server is sending compressed content to the client. We're using curl HTTP client. Look for Content-Encoding header field in the HTTP response returned from the web server.
$ curl -I -k --compress https://localhost
HTTP/1.1 200 OK
Date: Wed, 07 Aug 2013 16:36:35 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: PHP/5.4.9-4ubuntu2.2
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Content-Type: text/html

4. Disable mod_deflate and restart the web server again.
$ sudo a2dismod deflate
Module deflate disabled.
To activate the new configuration, you need to run:
  service apache2 restart

$ service apache2 restart

5. Recheck the HTTP response Content-Encoding header. It should be missing from the result returned.
$ curl -I -k --compress https://localhost
HTTP/1.1 200 OK
Date: Wed, 07 Aug 2013 16:42:53 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: PHP/5.4.9-4ubuntu2.2
Content-Type: text/html