php – How can I prevent systems from embedding my site?

Question:

I recently discovered that people are accessing my website with an advertising application (Site Marketing).

Every time it comes from different "people", with different data but with the same characteristics.

It starts with text and at the end some links.

I also found out that the tool prevents JavaScripts from running along with the page and simulates Internet Explorer 6 version.

  1. What would be the idea, block access via iframe. Prevent the page from running on outdated versions of such browsers.

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

  3. Putting "CPF" field with verification (Validation) which in this case is already inactive.

Answer:

"I also found that the tool prevents JavaScripts from running along with the page and simulates the Internet Explorer 6 version."

There are even software that are not browsers that send/receive data via HTTP(S), such as CURL. Not far away there is the LYNX Browser, which is simply text, a CMD browser . Furthermore, 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 in an <iframe> or a <frame> , so use:

NGINX:

  add_header X-Frame-Options "DENY" always;

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

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

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

Any Burp Suite allows changing the headers, any CURL allows defining the 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 it via Chrome version 41, even CURL has a -A function especially to change the User-Agent , without having to use the -H , cool isn't it ?!

One thing you can do to break old browsers and prevent old browsers from being used is to use TLS 1.2. Just to be clear TLS 1.2 was not made for this but only recent browsers and recent operating systems support it , ie it is a "natural" elimination.

Putting "CPF" field with verification (Validation) which in this 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 CPF at no cost , a malicious person will continue using and making several and various requests normally. The only way would be if you verify that the CPF matches the name and other data, even then a lot of data can be obtained by searching Google itself.

Note This role was created based on this publication .


You create CPF restriction and require lots of data will drive away legitimate users. As well as blocking old browsers, it only tends to reduce the number of legitimate visits, without any great benefit. Of course, if you use TLS 1.2, and as a consequence prevent old browsers , your site will be more secure than SSLv2 and SSLv3, but blocking for blocking will not bring any benefit .

Also, those who really want to manipulate will get it using CURL or whatever it is, forging a User-Agent, which in fact if they use it they'll already forge (and you can't even find out).


Efficient solutions:

  1. Use X-Frame-Options for modern browsers not to allow iframe, if limited by TLS 1.2 it will support this header .

  2. Adding captcha could increase the cost for counterfeits, may create a small inconvenience for the user .

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

  4. Create a Rate-Limit case a single IP sends many requests and I blocked it preventing new sendings, if this is the case .

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

Scroll to Top