I'm creating a web page where users can register themselves and their newly bought product.
So the page initially consists of two input fields: A serial number and their social security number. These values are to be validated against two different API's. The users should not be able to abuse these API-calls since second one costs money for each call. The other one should also be restricted in some way so that users can't get access to all our serial numbers.
And the wish was to make this web page with ajax to create a good user experience. So I'm using the jQuery ajax function to call webmethods that I've put in the codebehind of the page.
In turn, each webmethod calls the matching API using credentials. But doesn't this mean that anyone can edit the script clientside so they can make how many calls they want to the API's?
I need to be able to prevent this. how would I go about doing that? Can I check that the call wasn't initiated by user-inserted script?
Another question, how do I validate on client side that both ajax calls have returned successfully? it's easy if there was only one ajax call. I would just do something in the success: part of the ajax function. I could check that all checkmarks are visible next to the input fields, but that could be easily tampered with by users. SO what is a good way to do this? I want to enable a button once both calls have been made succesfully, so that the user can confirm the results from the API's.
[WebMethod]
public static string CheckSerialNumber(String _input)
{
string result = null;
var client = new CheckSerialNumberClient(); //A service reference to the API
try
{
//make the API call.
result = client.checkSerialNumber(_input);
}
catch (Exception)
{
result = "An error occured";
}
return result;
}
[WebMethod]
public static string GetCustomerInfo(String _input)
{
string result = null;
var client = new CustomerInfoClient(); //A service reference to the API
try
{
//make the API call.
result = client.getCustomerInfo(_input, myCredentials); //credentials is so that the company that has the API can charge us for each call.
}
catch (Exception)
{
result = "An error occured";
}
return result;
}
jQuery, I got this to work, but might as well show it. This is after the input has been validated against a regex:
$.ajax({
type: "POST",
url: "/Default.aspx/CheckSerialNumber",
data: ...
contentType: "application/json; charset=utf-8",
dataType: "json",
success: function (msg) {
return true;
}
You can make CheckSerialNumber return a nonce (single use key) which will have to be used (and then verified server side) when calling GetCustomerInfo. This will force your api users to go through CheckSerialNumber before moving on to GetCustomerInfo.
This will solved the problem with calling GetCustomerInfo without going through serial number verification first, but will not prevent someone from calling the first and then the other repeatably until you run out of cash, provided they have at least one verified serial number.
You could limit the number of calls per serial number in which case an attacker will have to generate a list of valid serial numbers (not sure how easy this is)
You can check for the request ip and try to limit calls like that, but honestly it is very difficult to prevent someone determined enough from bypassing such limitations, and so usually such attacks are handled on the network level. If you're using SSL this would make life a bit more difficult as IP spoofing is not possible when using SSL as far as I know, but again, it's not bullet proof.
Setting cookies etc. is not relevant as deleting cookie or ignoring them is very easy when using attack tools.
As for confirming that all went well, in the success method of the first call, you can call the second verification (if you implement a nonce key you'll have to do it this way anyhow). Then in the success method of GetCustomerInfo you can confirm that it verified successfully as well.
As a last resort, limit the number of calls you make to the client.getCustomerInfo api in a given time frame, so if someone does bypass your limitations, you can limit the impact the intrusion has by limiting the money you pay for that service. For example you can say that on average you have 100 calls a minute, so anything above 200 calls per minute should stop the service from serving new requests until you understand if it's a surge of real requests or an attack.