Using soft limits to prevent abuse with good user experience

When you develop a service you will probably run into a situation where you want to put in some arbitrary large limit on something to prevent bad behaving clients from using too much of your resources. This can be a max length of the URI, max length of each request header, max size of a request and so on. What we tend to do is often to return some kind of error when this happens and expect the client to fix their request if it is legitimate. But what if it is a legitimate request - just something you didn't expect to be valid? Or what if there is a bug in the client, but the user have no way of fixing the client but rely heavily on your service? Do you really want to completely break your users in these cases?

What is the most vulnerable operating system?

For whatever reason I needed some data on what the most vulnerable operating system was and instead I stumbled over some questionable use of statistics. At least in my opinion.

When your employer is phishing

A couple of months before I left my previous job I received a suspicious email - apparently I've received a fax and it was inside a linked PDF. I was a little bit surprised when I looked into what this really was about.

Preventing cross-site request forgery (CSRF)

Since I stumbled over a pretty good introduction to what CSRF is I figured it was worth a few lines.

All you ever wanted to know about password hashing

Well sometimes I'm lucky and somebody else writes something so I don't have to. Since you should assume that your system will be breached eventually you should make sure that your user's  passwords cannot be exposed as a lot of users reuse their passwords across multiple sites.

Go, maps and randomization

A couple of years ago it was very easy to DoS attack .Net web services as the headers were added to a dictionary. Back then the hash of the key was predictable so using a bunch of machines in azure and a few days it was possible to generate enough strings that resulted in the same hash value that you then could make a fake request with a lot of headers (a few hundred is typically enough) that caused the web server to spend 100% of CPU searching and updating the header dictionary. Since I recently started doing some work using go (aka golang) I immediately started to wonder how this worked in this language.

Do I need to remove the Server header from my HTTP responses?

You might have heard the recommendation that your web server should not return the Server header to reveal exactly what software is being used. It even says so in the RFC. Given how hard it was to remove the Server header when using .Net HttpListener you might wonder what is really the right thing to do here.

Is logging raw HTTP requests ok?

When you are working on services that need to scale to millions of users you typically come to the conclusion that you will never be able to start a debugger on one of your live services. Instead you need instrumentation (also known as logging, tracing or diagnostics) to make sure you can figure out what went wrong. What I see happening a lot is that developers start logging the raw HTTP request to capture all data. And there are several problems with this approach...

Preventing DoS attacks with puzzles

So when a web service is getting too much traffic it starts returning the 503 status code. Well written services also return the Retry-After header hinting the client when it should come back again. Good behaving clients then respect that or will back-off by themselves to make sure the server is not getting too much traffic. However this is not enough if there are bad behaving clients in the mix. And how do you identify the bad behaving clients?

Secure(r) IIS settings

If you are using IIS as a webserver you are probably interested making sure the service is configured to be as secure as possible.

Understanding HTTP Strict Transport Security (HSTS)

I'm not going to explain it all myself since it was explained in an excellent way here. However below is the executive summary.

Black Hat USA 2015 report

Last week I told you about my training experience at Black Hat 2015. Now it is time to talk to you about the briefings and the business hall.

Black Hat USA 2015

I'm attending Black Hat 2015 USA. This is my first time at Black Hat or any other security related conference and here are my first impressions.

Returning 403 or 404 - that is the question

I think it is safe to say that anybody who is serious about security will tell you that security through obscurity is no security. Yet a lot of people think obscuring is a great way to increase security like for example return 404 rather than 403 on REST APIs when the caller does not have rights to retrieve an existing resource.

Email as password manager?

A lot of people these days rely on some (software) password manager to keep track of all different passwords you need. Obviously there are two risks with this approach.