You’re not always right and that is ok

How do you feel when you realize that a decision you made or an action you took wasn’t as right as you thought?

For me, being right is something I try too hard for, almost. I have spent most of my life living over cautiously to make sure that what I was doing was right. I am typically quiet on topics unless I believe my response is right. I do this because I don’t want to fail. I don’t want to be wrong.

When it comes to security, I think this is a common feeling. Those in the security industry want to be right. We want to feel like we are doing something positive and to be honest, there is a fear that if you are wrong you will not be taken seriously.

The thing is. we won’t ever be 100% right all the time. It doesn’t matter how long you have been doing this, there is always something new to learn. In my case, it wasn’t really something new, it was just a situation where I had too narrow of a focus. Being wrong was actually a wake-up call to realize that things are not in a vacuum.

So what happened?

During a test last year I identified what I considered to be insufficient server-side validation. We have all seen the forms, for example changing your password, where it requires you to enter your password twice. That second text box is a confirmation box attempting to verify that you didn’t mistype your password the first time. The idea that if you typed it twice, you wouldn’t have mis-typed it.

In this case, the server was not validating the confirmation password. Instead, it just used the new password value and stored it. Through testing, it was clear that it didn’t matter what I put in that confirm password field, the new password was always accepted.

When we think about validation, we always talk about server and client side. We can’t trust the client. So from a non-contextual stand point, this is a clear issue where the new password and confirm password fields are not validated on the server to match.

When I met with the client to go over the report this finding came up. The developer’s stance was that the confirmation is there on the client to make sure they use the password they think they typed, but not necessary on the server side. To be fair, this caught me off guard. The more I thought about it, and I still think about it today, the more I agreed that he was spot on.

In this scenario, the weakness is that the user may mistype their new password the first time and the confirmation field would alert them to the mistake. This makes sense as a client-side validation. But how does it make sense from a server-side validation? What would the attack scenario look like? How would an attacker abuse this? From a raw request standpoint, it is nothing to set to fields to be the same. So setting them different doesn’t gain any advantage.

I realized that I hadn’t given this finding enough thought, rather I just jotted it down. It was a low risk finding. It could have also been an indicator of other locations that might not be performing server-side validation. But in its application, this was not a risk that would need addressing as the client-side validation was sufficient. In fact, there are many applications that no longer require a confirmation field with creating new passwords.

Security is changing every day. Things that were once top priority are now low priority. Things that were not an issue yesterday may be one today. When working with your clients make sure to think through these types of scenarios. It is easy to quickly find something and write it down. The ability to accept that something may not be what it seems can go a long way in building relationships with those you are supporting. It allows them to feel more comfortable asking these types of questions knowing that you are actually listening.

Don’t be afraid to ask questions or share your opinions when it comes to application security. There are so many things to know and learn, you are bound to say something wrong. If that is the case, take the opportunity to learn what is right and not dwell on being wrong.