Betfair Client-side Validation

Data validation is often an important step in modern web applications, both for functionality and security purposes.  For example, if a user is required to enter a phone number in a form it makes sense to validate that it has the right number of digits and only contains numerical data.  If entered incorrectly a message can be displayed back to the user requesting them to fix their error. There are two primary types of data validation, client-side and server-side.  Client-side validation is carried out in the user’s browser.  This is often done using something like JavaScript or HTLM5 attributes.  The problem with client-side validation is that it can often easily be bypassed.  This is where server-side validation comes to the rescue.  In server-side validation the user’s input is examined at the server level, rather than the user’s browser.  This method is much more secure; one of the keys to secure programming is not to trust the user.  It is often recommended to initially perform client-side validation, but then also perform server-side too.

This leads to an example of data validation being performed incorrectly in the Betfair iGaming New Jersey web application.  During the user registration process a password must be selected.  The password must meet certain requirements (8 characters, 1 number, 1 special character, 1 uppercase).  The web form does performs both client-side and server-side validation during this initial registration process in order to validate the password.

However, once a user and password has been created a user has the option to change their password from within the application.  This is where the developers made a mistake and only performed client-side validation.  As you can see in the figure below when a weak password is entered client-side validation occurs and a “weak” password cannot be used.

A password that meets the requirements (P@ssword1) is then entered and the data is validated correctly on the client side.

But, before submitting the POST request to the server it is intercepted using a local proxy.  Below you can the original request with the password value being P@ssword1

Before we pass the request on to the server we modify the password value to pass.  This is a password that should not be accepted as it does not meet Betfair’s password requirements.

The request is forwarded on to the server and as you can see in the figure below the password was changed successfully.

In order to show that the password was changed to an invalid value we then login into the application using the new password as seen below.

The login is successful!

While in this example there is not much risk, all the user can do is bypass the data validation and select a password that does not meet the password requirements.  However, if the developers made this mistake in this area it is possible that similar errors in data validation were made in more sensitive and important components of the application.

As a note Betfair was notified of this issue at the end of March.