Posts

If you ever developed with Docker, you have to acknowledge that it is great! Ok… you have to wrap your brain around an additional layer with all those caveats we know and love (volumes, path in- and outside of containers, …), but it lets you bundle all your dependencies at build time and then ship an image that will run in every docker-compatible runtime! When you develop with Docker and do a lot of start/stop/build actions you will inevitably clutter your Docker Host with many unused containers.

In one project at work we implemented a passwordless login where you enter your email and then prove that you own this email-account by clicking on the link we sent you. When I tried to log in with my (mistakenly uppercased) email-adress [email protected] I got an email, but this was not my account… It was empty. Then it struck me. I used the entered email as a case-sensitive identifier to the account and obviously "Erdii@werise.

Imagine a commentbox, where each comment has to be approved by the moderator in his backend. If the backend used GET requests for the comment moderation, the url to moderate a post should look something like this: http://yourdomain.com/moderate/:decision/:postid For example: http://yourdomain.com/moderate/allow/1 http://yourdomain.com/moderate/deny/2 … If some evil person posted a comment and knew their postid (lets say 12) they could try to email you a link to http://yourdomain.com/moderate/allow/12 with a caption that says Cute cat gifs, you would click on it and BOOM the comment would be published…

When a webapp takes user input (like a blog post or comment) and later renders that input into a HTML-Page, the webapp has to ensure that no malicious <script> tags or anything else is delivered to the viewer. How to do that is actually pretty easy… Just replace " ' < and > with their HTML-Entity-Counterparts. But when do we have to do it?? Because we want the input’s author to see the exact same thing she entered into the text field, the webapp should not sanitize the text before it gets saved into the database, but rather before it gets delivered to the viewing client.

This is my example Nginx reverse-proxy + hardened https config (you need nginx/1.9.9): # redirect all http requests to https server { listen 80; server_name www.werise.de; server_name alias.werise.de; return 301 https://$server_name$request_uri; } # define a new cache (use different names and paths for different caches! proxy_cache_path /var/nginx_cache/blog.werise.de levels=1:2 keys_zone=blog_cache:10m max_size=512m inactive=60m use_temp_path=off; # https server block server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name blog.werise.de; ssl_certificate /etc/letsencrypt/live/mydomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/mydomain.