Making query

Chapter 1. API Variables

Here you can find the variables that our API accepts.

Note that the variable names except the data variables start with an underscore character.

_api - This variable is used for authentication of EXT to FRH. The API code can be generated by the USER on the FraudHosting Panel, under “Reporter Profiles” menu.

_action - Action can be “report” or “query”. “report” is for submitting a new client to our system, and “query” is for asking information about a client.

_type - Type is the short definition of the offensive behavior. Billing system module developers can offer pre-defined options such as ‘staff abuse’,‘support abuse’,’too many support tickets’,‘chargeback’,‘stolen card’,‘fraud’,’early cancellation’,’non-payment’,‘illegal hosting’,‘criminal intent’,’excessive server load’,‘public threats’,‘other’. Custom values are also accepted. Lowercase characters are preferred. Any uppercase character will be converted to lowercase in our database.

_text - Text is the block of information submitted by the USER. Any information posted will be publicly visible by any other USER that queries the same client. This is the only field where lowercase, uppercase, or any other character can be mixed. Any end user must be discouraged to submit private client information through this field, since the contents of this field will be visible by other companies that query for the same client.

_value - An integer value between 1 and 10. This is the level of the offensive behavior. 1 means very low importance, 10 means highly dangerous. 5 can be considered as Moderate Level. Typically any value below 5 will not require the company to terminate the client account, while values above 6 should be a basis for termination of service of the CLIENT.

Data variables

Data variables are the core of the FraudHosting system. They are used to transmit CLIENT information from USER to FRH. They are salted hashes of lowercase values of the client information.

Data variable names can be anything between 1 to 16 lowercase characters, however a standardization is highly encouraged. Some samples are as follows:

Any other variable can also be submitted as long as the variable name consists of [a-z] characters, 16 characters max. Uppercase variables will be converted to lowercase by FRH internally. Dash (hyphen) character is also accepted. For example, “paypal-email” is a valid variable name.

You can submit multiple variables with the same name, by adding a number to the end. For example, email, email2, email3, …, email9 will all be accepted as “email” into our system. The added number doesn’t count against the 16 character limit, but it must be a single digit. The digits don’t need to be in order. You can simply submit “email5” and our system will read it as “email”, even if there aren’t any other email fields.

Values of Data Variables

All those data variables have a single format for their values. Trimmed, lowercased, salted, and hashed, in this order. Best way to explain is to give examples.

Any of this information can uniquely identify this client across many companies. If John Smith committed misbehavior, for example making a chargeback after several months of service use, the hosting company will want to report this incident to FraudHosting. The billing system of the company will need to submit his information in this format:

Calculation of Data Variables

There must be a standardization for certain variables. Here are the rules:

• All values must be stripped off the spaces between the characters, and at the beginning/end.
• George Michael must be sent as georgemichael
• Strings like names, emails, postal addresses, domain names, must be passed through an english alphabet lowercase function.
• Domain names must be stripped off the initial www. part, or http:// part. Plain names like example.com are valid, as well as subdomains.
• Plain hosting account passwords must NOT be made lowercase, since their uppercase characters are their defining values. Already hashed passwords should be made lowercase.
• IP Addresses must be in regular format, like 123.45.67.89
• Whitespaces before and after the variables must be trimmed.

Limitations on the Data Variables - BLACKLIST

There are several pre-defined pre-hashed values that are ignored by our system.

Some common dummy values, such as “John Smith”, “John Doe”, and “127.0.0.1”. Single characters like “a”, and most repeating characters, such as “1111111111”, “aaa”, “—-”. Some sequential numbers that start with 0, 1 or 9. Such as “012345678”, “1234”, “98765”. Some phone numbers, such as “555-555-5555”

Full blacklist available as hashvalue:data format here

These pre-defined values have been hashed for blacklisting in our system. Any dummy value that we may have forgotten to blacklist will be allowed. Since we can’t see the original data source of the hashed value, we cannot define rules for limitations that cover every possibility. We did our best to manually add those blacklists. If you encounter a dummy value that should have been rejected by our system, please inform us and we will add them to the blacklist.

If you are developing a billing system integration, make sure that you are NOT using these values as test items. They will be silently ignored as if they are not sent at all. You can use your own dummy values, and at the end of testing, delete your reports.

The Hashing Function

The hashing function used to create the hashes is a salted SHA-1 function with 32,000 iterations. The salt is a prefix, namely “fraudhosting-”, appended to the beginning of the standardized variable before each hashing.

Hash function must produce hexadecimal values like “ac2c739924bf5d4d9bf5875dc70274fef0fe54cf” represented as strings. Binary representations are discouraged.

Pseudo Code:

FUNCTION prepare_value ( value )
	TRIM the WHITESPACE characters from VALUE,
		including NEWLINE and TAB characters		
	REMOVE SPACE characters from value 				
	LOWERCASE value using english alphabet characters		
	RETURN value		
END FUNCTION
	
FUNCTION fraudhosting_hash ( value )
	FOR 32,000 TIMES LOOP
		value = "fraudhosting-" + value
		value = SHA-1( value )
	END LOOP
	RETURN value
END FUNCTION
	
hash = fraudhosting_hash ( prepare_value ( value ) )

Sample PHP Code:

function fraudhosting_hash($value) {
    for($i = 0; $i < 32000; $i++)
        $value = sha1("fraudhosting-".$value);
    return $value;
}

$name = "John Smith \n";
$hash['name'] = fraudhosting_hash(strtolower(str_replace(" ","",trim($name))));
// processed as "johnsmith"
// result is ac2c739924bf5d4d9bf5875dc70274fef0fe54cf
    
$password = "iLoveLinux!";
$hash['password'] = fraudhosting_hash($password);
// processed unchanged, as "iLoveLinux!"
// result is 93491c2dff7b35528c319f304b0222fc55ebcfcb
    
$phone = "+1 000 111 22 33 ";
$hash['phone'] = fraudhosting_hash(str_replace(" ","",trim($phone)));
// processed as "+10001112233"
// result is 3f09086d8d4e4019eb534ce28e6b64c8ef563ec9

Once the EXT billing system generates these values, they can be submitted through GET or POST requests, along with the other variables like _api.

Security Considerations

Submitting a hashed version of the credit card number is quite safe for the following reasons:

• Salted Sha-1 hashes are the industry standard for one-way encryption of sensitive values. Salting prevents pre-made rainbow table attacks.
• 32,000 iterations ensure that a brute-force attack is very expensive compared to a single iteration sha-1 function.
• All values are transmitted through an SSL protected gateway to our database.
• There is no API or web panel access to the stored values in our database, unless the USER submits the same value for cross-checking.

Credit card numbers are very good ways to uniquely identify a client between different companies. It is advisable to include them in applicable reports.

$url = "https://api.fraud.hosting/api/";
$data = [
  '_action' => 'query',
  '_api' => 'a51ff508c331b7e9',
  'name' => '7b30981dd586b87ea42ea864c03abd2ce9086520',
  'email' => 'ba65e95764ee08a38bff8d281ad0dcbbe86c9b64',
  'ip' => 'ee302279497c4c79a2e64c532d01ba4bb3b57a0c'
];

$options = [
  CURLOPT_URL => $url,
  CURLOPT_POST => true,
  CURLOPT_POSTFIELDS => http_build_query($data),
  CURLOPT_RETURNTRANSFER => true,
];

$ch = curl_init();
curl_setopt_array($ch, $options);
$response = curl_exec($ch);
if (curl_errno($ch)) {
  echo 'Error:' . curl_error($ch);
} else {
  echo $response;
}
curl_close($ch);

import requests

url = "https://api.fraud.hosting/api/"
data = {
  '_action': 'query',
  '_api': 'a51ff508c331b7e9',
  'name': '7b30981dd586b87ea42ea864c03abd2ce9086520',
  'email': 'ba65e95764ee08a38bff8d281ad0dcbbe86c9b64',
  'ip': 'ee302279497c4c79a2e64c532d01ba4bb3b57a0c'
}

response = requests.post(url, data=data)

if response.ok:
  print(response.text)
else:
  print(f"Error: {response.status_code} - {response.text}")

const https = require('https');
const querystring = require('querystring');

const data = querystring.stringify({
  '_action': 'query',
  '_api': 'a51ff508c331b7e9',
  'name': '7b30981dd586b87ea42ea864c03abd2ce9086520',
  'email': 'ba65e95764ee08a38bff8d281ad0dcbbe86c9b64',
  'ip': 'ee302279497c4c79a2e64c532d01ba4bb3b57a0c'
});

const options = {
  hostname: 'api.fraud.hosting',
  path: '/api/',
  method: 'POST',
  headers: {
      'Content-Type': 'application/x-www-form-urlencoded',
      'Content-Length': data.length
  }
};

const req = https.request(options, (res) => {
  let responseData = '';

  res.on('data', (chunk) => {
      responseData += chunk;
  });

  res.on('end', () => {
      console.log(responseData);
  });
});

req.on('error', (error) => {
  console.error('Error:', error.message);
});

req.write(data);
req.end();