**Read Part 1 to get the full picture of post**

Notice that there is no user confirmation that the phone number is correct and that I really do want to receive the results via SMS especially because receiving the results comes at a cost of B$3.00! Yes it does give a cancellation code which I could have sent back to not receive the results SMS. The delay between the 2 SMS’s was 3 minutes which is ample time to send a reply, if you are actively checking your phone.

Exploit #1: Overwhelming a single person with many result SMS, and having them be charged at $3.00 a piece. If the person is using a prepaid plan, you could effectively use all their credit creating a denial of service attack. If they are using a post paid account they could just rack up the charges.

Solution: Request users to send a confirmation SMS saying they do indeed want to receive the results.

Taking things a bit further I tried a few things like putting invalid data. Good enough they did validation of the data I put in.

After some investigation I found that the problem of this validation is that lies solely on the fact that they used Javascript alone to do the validation check. Javascript being a client side processing means that it can be subject to change. Firefox users have Greasemonkey and Opera users have user scripts. Or you can do what I did and view the source of the page, copy it to a local file, make the necessary changes to the source, load it up without validation checks and send the form on. And what did I do? I registered a my friend’s foreign mobile phone number. My friend confirmed that he received the results SMS despite the fact that he is not in Brunei. This leads to exploit #2 which could effectively rack up foreign SMS charges to SMS gateway that is providing this service.

Exploit #2: By pass client side validation of data

Solution: Use server side validation of data, in this case in the PHP code

This exploit relies on the fact that the application assumes that the information it receives is valid data. This should never be the case. You cannot assume that the user will input the correct information, you must sanitize the data accordingly to ensure that you only have valid data in your application. It is things like this that lead to SQL injection which could cause catastrophic results on your server and even information theft. So whenever designing and implementing any system, you as a developer should do you job properly and factor this in and ensure your application does not suffer from this flaw.

PS. This being my first vulnerability disclosure was indeed an experience but and it didn’t go too well I have to say. After I emailed them regarding this issue they didn’t even get back to me. I had to call them up 2 weeks after that to ask if they got it and apparently my email just happened to disappear somewhere. Go figure… So the guy I was talking to gave me his direct email address and he thanked me for my input saying that there are some things that they could change and some things they couldn’t. After another month and 2 emails I sent asking for updates, there was still no word from them. But 3rd times a charm and I finally got a reply saying that they fixed some of the Javascript. Despite that not being the best solution I felt I had waiting long enough and came to disclose the problem. It’s not even a hard fix to implement. Oh well. I shall wait for a reply from the next organization who I sent another security concern too. So far no reply after 3 days.. So I wait….