How can I stop systems from incorporating my website?

Question

A little while ago I discovered that people are accessing my site with a marketing application (Website Marketing).

Ai every time comes from different "people", with different data but with the same characteristics.

Start with a text and at the end some links.

I also found that the tool prevents Javascrips from running together with the page and simulate version of Internet Explorer 6.

1. What would be the idea, block access via iframe. Prevent the page runs in outdated versions of such browsers.

2. Prevent the page from running in outdated versions of such browsers.

3. Placing "CPF" field with verification (Validation) that in the case is already inactive.

Answer 1

"I also found that the tool prevents Javascrips from running together with the page and simulate version of Internet Explorer 6."

There is even software that is not browsers that send/receive data via HTTP(S), such as CURL. Not far away is the LYNX Browser, which is simply in text, a browser in CMD. In addition even Chrome and "real" browsers are able to turn off javascript in their settings.

---

What would be the idea, block access via iframe.

There is, the header/header of X-Frame-Options (RFC 7034), since 2013, it aims to prevent a website from opening on a <iframe> or in a <frame>, so use:

NGINX:

  add_header X-Frame-Options "DENY" always;

But if the browser is obsolete? If the browser does not interpret the X-Frame-Options this will be ignored.

Prevent the page from running in outdated versions of such browsers.

This is useless, a malicious person can quickly fake a User-Agent, the CURL itself, which is not a browser can pass for a fast and easy browser.

Any Burp Suite lets you change headers, any CURL lets you set headers, this:

curl -H "User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36" https://seu-site.com

Makes your website understand that you are accessing via Chrome in version 41, including CURL has a function -A especially to change the User-Agent, without having to use the -H, not legal?!

One thing you can do to break older browsers and preventing older browsers from being used is to use TLS 1.2. Only to make TLS 1.2 clear wasn’t made for this but only Recent browsers and recent operating systems support it, or is a "natural elimination".

Placing "CPF" field with verification (Validation) that in the case is already inactive.

It is faster to generate a CPF than to generate an MD5, for example this generates a valid CPF:

$CPF = '';
$D10 = $D11 = 0;

// Gera 9 números individuais pseudo-aleatorios criptograficamente seguros
for($i = 0; $i < 9; ++$i)
    $CPF .= random_int(0, 9);

// Calculo do 10º número
for($i = 0; $i < 9; ++$i)
    $D10 += $CPF[$i] * (10 - $i);

// Acrescenta o 10º número ao CPF (Se for maior que dez é 0, se não é ele mesmo!)
$CPF .= 11 - ($D10 % 11) >= 10 ? 0 : 11 - ($D10 % 11);

// Calculo do 11º número
for($i = 0; $i < 10; ++$i)
    $D11 += $CPF[$i] * (11 - $i);

// Acrescenta o 11º número ao CPF (Se for maior que dez é 0, se não é ele mesmo!)
$CPF .= 11 - ($D11 % 11) >= 10 ? 0 : 11 - ($D11 % 11);

echo $CPF;

You can generate thousands of Cpfs at no cost, a malicious person will continue to use and make various requests normally. The only way would be if you check if the CPF matches the name and other data, even then a lot of data can be obtained by searching on Google itself.

Note that function has been created based on this publication.

---

You create restriction by CPF and require multiple data will ward off legitimate users. Just like blocking old browsers, it only tends to reduce the number of legitimate visits, without any great benefit. Logical if you use TLS 1.2, and as a consequence prevent old browsers, your website will be safer than Sslv2 and Sslv3, but blocking by blocking will not bring any benefit.

Besides who really wants to manipulate will achieve using CURL or whatever, falsifying a User-Agent, which actually if they use they already fake (and you can’t even find out).

---

Efficient solutions:

1. Use the X-Frame-Options for modern browsers do not allow iframe, if you limit by TLS 1.2 it must support this header.

2. Adding captcha could increase the cost for fakes, can create a small inconvenience for the user.

3. Define a Content-Security-Policy to also prevent the <iframe> and also XSS.

4. Create a Rate-Limit if a single IP sends many requests and blocks it by preventing new submissions, if this is the case.

5. Create fake forms, not visible to humans, as suggested by @Bacco, can be efficient.

Answer 2

I believe that your problem is totally related to some Bots attack, that is your problem is not to include your site elsewhere, but rather one or more Bots that try to break the security of your site, or even try to cause some kind of mass attack to take down.

So the issue here is not a cross-site scripting (XSS) problem, but a direct attack.

Your solution to create a hidden field, really I did not understand, but if it is what I imagine, any BOT can easily detect it and pass over it soon.

The existing solutions to solve this type of problem today are:

• Create your own image captcha
• Use recaptcha
• Using services such as https://www.cloudflare.com/ - more details on https://www.cloudflare.com/br/waf/

Answer 3

People just reopening the question I asked myself, I poked around further, I gathered some ideas here from the post, and I did the following.

In the form itself I put a hidden field with very similar name that possesses in the tool, the field was of type text and not Hidden and was hidden with css.

With this I solved in 100% the spans that was received in all emails that were fired from the form. No emails with links, or with similar content were received!

CASE SOLVED.