Files van een website verbergen voor zoekmachines ?

Status
Niet open voor verdere reacties.
L

leifoet

Gebruiker
Lid geworden
7 okt 2007
Berichten
326
Kunnen bepaalde files in een website 'verborgen' worden voor opvraging door zoekmachines ?
Zijn de modaliteiten verschillend voor bijvoorbeeld Google vs Bing vs ... ?
Hoe scoort een dergelijke methode inzake beveiliging ?
...

Dank voor tips.
 
Je kan een robots.txt bestand plaatsen met:

Code: 
User-agent: *
Disallow: /documents/

Hiermee kan je voorkomen dat de meeste zoekmachines alle inhoud van /documents niet zullen indexeren.
Je kan nooit voor 100 procent aannemen dat ze dit allemaal doen.

Anders is de beste oplossing om ze achter een authenticatie te plaatsen. Je moet de bestanden dan buiten de webroot (buiten /public_html, /www of /htdocs) plaatsen zodat niemand er meer direct bij kan, en met PHP kan je dan zoiets maken (ongetest) zodat je het enkel kan downloaden zodra je toegang hebt. Spreekt voor sich dat je zelf een inlogsysteem moet hebben:

PHP: 
<?php
if(isset($_GET['file'])) { 
   if( is_authenticated() ) { // maak zelf de functie om te controleren of iemand toegang heeft.
      // toegang
       header('Content-Description: File Transfer');
       header('Content-Type: application/octet-stream');
       header('Content-Disposition: attachment; filename="'.basename($_GET['file']).'"');
       header('Expires: 0');
       header('Cache-Control: must-revalidate');
       header('Pragma: public');
       header('Content-Length: ' . filesize($file));
       readfile('../documents/'.$_GET['file']);
       exit;
   } else {
       echo "Geen toegang!";
   }
} else {
echo "Geef een bestandsnaam mee in de URL!";
}
?>
 
Laatst bewerkt:
Kunnen bepaalde files in een website 'verborgen' worden voor opvraging door zoekmachines
Klik om te vergroten...
Antwoord is simpel : Nee!

Er bestaan honderden bots met allemaal een bepaald stukje tekst in de User Agent string. Een bot kan zich ook voordoen als een gewone browser. Op mijn pc heb ik HTTrack die zich voordoet als een gewone browser op een Windows pc terwijl het toch een bot is.

@leifoet Hoe scoort een dergelijke methode inzake beveiliging ?
Klik om te vergroten...
Ik begrijp niet goed wat je bedoelt met beveiliging?

Een voorbeeld lijst van bot strings vind je hier maar er zijn er nog veel meer en je hebt er niets aan.
 
Het is mogelijk maar moeilijk zie random keys .
Je moet overwegen of het files van externe bron zijn of interne bron om betrouwbaarheid te kennen.
Files kunnen opties bevatten zoals (virusen scripts urls) met hun eigen kwetsbaarheden.

Volgende lijn gebruik je niet
PHP: 
readfile('../documents/'.$_GET['file']);
Reden : HET IS NIET VEILGIG onmiddelijke toegang te geven aan uw bestandsysteem.
valideren doe je dan met regex Laat geen waardes toe die van buitenaf komen met [..] / & laat enkel char cijfers en één puntje toe.

Dus aanvraag zal

domein.ext/vraag/doc?key=XXXXXXXXXXXXX_uniekkey_extradownloadcode

je kan een domeincode hebben die aanpast per maand automatisch = uniekkey
je kan voor elke download een sleutel maken om deze te downloaden.

maak ook een vingerprint van de gebruiker met browser en of ip excetra dus object met sessioncode . zo kan je zoekrobots uitsluiten indien deze langskomen.
 
@kenikavanbis. De TS vraagt of normaal toegankelijke pagina's verborgen kunnen worden voor bots.
Ik vermoed dat je een antwoord geeft op een andere vraag ;)
 
Ok dan met handen en voeten .
Eerst moet je weten of de files intern of extern zijn.
Is die potentieel besmet met virus?
Je wil geen files door scripts halen die besmet zijn.

(dit zou ik veronderstellen dat je zelf zou kunnen bedenken)
Verder werk je met random char sleutels .
Bij het uploaden word een sleutel opgeslagen met bestandlocatie in een database.
Bij het downloaden word de sleutel gebruikt om te downloaden en zal de file door een script afgelevert worden.
En dan zou je moeten controleren hoe je minst risico loopt (fisieke file of file in database)(dus denk aan een ander database omdat je backups niet onhandelbaar groot zouden worden)

maar dit staat iets korter hierboven ook met een vb van hoe je key eruit zou kunnen zien.
 
Laatst bewerkt door een moderator:
... sorry, geraak (meer dan een beetje) overdonderd (... mijn te beperkte bagage ?!)

@kenikavanbis. De TS vraagt of normaal toegankelijke pagina's verborgen kunnen worden voor bots.
Klik om te vergroten...
Is inderdaad de probleemstelling sub #1
Betreft eigen pagina's => besmetting ?

@bron. Ik begrijp niet goed wat je bedoelt met beveiliging?
Klik om te vergroten...
Ben hier mogelijks te (?) kort door de bocht gegaan : als bepaalde pagina's niet zichtbaar zijn in bots, zijn ze dan veiliger (?)

... vraag blijft : is verbergen nu wel of niet mogelijk ;-) ?

@kenikavanbis.Reden : HET IS NIET VEILGIG onmiddelijke toegang te geven aan uw bestandsysteem.
valideren doe je dan met regex Laat geen waardes toe die van buitenaf komen met [..] / & laat enkel char cijfers en één puntje toe.
Klik om te vergroten...

Wat wordt bedoeld met een onmiddellijke toegang geven aan het bestandsysteem - is dat de volledige website ? Verschil onmiddellijke en niet-onmiddellijke toegang ?
Heeft regex te maken met 'verbergen' ? Of is dat een soort bijkomende login ?

Excuses voor mijn bijkomende problemen.
 
Laatst bewerkt:
Ik geef toe dat een betere controle op de $_GET zeker niet overbodig is. Een reguliere expressie zal wel helpen om te voorkomen dat iemand het pad in de URL kan aanpassen om bij andere bestanden te komen. Dat heet Path Traversal. Met bijvoorbeeld een ../ als directory kan je steeds een directory hoger gaan, en dat wil je niet. Dus daarom moet je met een reguliere expressie filteren op de invoer.

Daarnaast is authenticatie ook zeer van belang. In Kenika's geval gaat dit via sleutels. Maar dan moeten die niet zomaar "op straat liggen".

Ik vind alleen het verhaal over virussen overtrokken. Het gaat om het om documenten te beschermen tegen zoekrobots.

Dus mijn code is een goede leidraad, waar je enkel nog wat veiligheid in moet bouwen.

Ik ben benieuwd of Leifoet al iets van een inlogsysteem heeft?
 
Laatst bewerkt:
Sommige woorden worden iets aangepast om uit zoekmachines te blijven en kwaadwilligen niet op ideëen te brengen.
Kan je paginas beveiligen tegen bots of zoekrobots , ja en nee [de meeste geven aan via variabele $_SERVER ... browser dat zij binnen komen en dan zou je pagina's kunnen aanpassen]
Het zal niet veel uitmaken zij proberen anoniem binnen te komen. (er zijn lijsten te vinden op internet om in je .htaccess te plaatsen om zoekrobots te verhinderen)(voor je het gebruikt plaats het even hier zodat ik het even kan bekijken of er geen ongewenste opties zijn aangebracht)

Eerst de betreffende lijn die niet te gebruiken is:
Met wat kunstjes die ik niet wens uit te leggen is het mogelijk elke file te lezen en in sommige gevallen ook boven je documentroot (documentroot =zelfde als / binnen je website)(documentroot =zelfde als de map die chown www-data kreeg ) als je iets ziet dat begint met ../etc of dergelijke ziet mag denken dat het een poging tot hacken was.

Is de herkomst van bestanden belangerijk JA ZEKER . Het toevoegen van js script aan images die sessie stelen is hiervan een voorbeeld dan deel je een mooi plaatje via mail (zou men de mail kunnen lezen , maar ook volledig toegang tot je webmailbox krijgen) er bestaat free software die in eerste geval leuk is en goed. maar dan door kwaadaardigen met opties voorzien(zoals criptominen, indringmogelijkheden)(bij microsoft is de strategie niet het probleem aan te pakken maar de installatie te herinstalleren hierdoor zijn zij niet meer instaat hun systeem juist te beveiligen)maar dit is te ver afwijken van de ts

REGEX :
is al even aangehaald door iemand.
Ik noem het eerder een omkadering voor het detecteren van tekt binnen grotere tekst. Je kan het zien als een validatie en als ook afscherming het word veel gebruikt door programmeurs om leterkombinaties te gaan verbieden of enkel deze toe te laten.
Bekijk even volgende
https://httpd.apache.org/docs/2.4/en/howto/htaccess.html
https://stackoverflow.com/questions/5249779/how-to-use-regex-in-file-find
Ik vermoed dat dit al de oplossing van je probleem kan zijn als je enkel files naar buitenaf wil afschermen.
ALS JE TEST niet in root van je domein maar in een map zodat je niet ftp blockeert of je eigen iprang (als je ooit problemen hebt met een .htaccess file kan je die verwijderen met phpscript )(Merk op dat je ook je eigen .htaccess file kan verbergen voor externen in vele gevalen doet de hosting dit voor jou zij verhinderen elk bestand dat start met .)
 
Laatst bewerkt:
Zet voor beveiliging het onderstaande in bestand .htaccess (bestandsnaam begint met punt) en plaats dit bestand in de root van je website. Dit vergroot aanzienlijk de beveiliging van je website. Waterdicht wordt het nooit maar hiermee zijn de meest bekende gaten gedicht. Het kan zijn dat je provider er al een paar heeft gedaan maar het kan geen kwaad als het nog een keer in .htaccess staat. Waarom een extra bestand .htaccess? Dit bestand wordt door Apache (de webserver software) gebruikt voor controles, aanpassingen en acties voordat iemand jouw bestanden kan uitlezen.
Code: 
### website in folder /dir or in root /
RewriteEngine on
RewriteBase /

### prevent directory listing
Options -Indexes

### hide server info
ServerSignature Off

### block .htaccess and .htpasswd
<FilesMatch "\.(htaccess|htpasswd)$">
Order allow,deny
Deny from all
</FilesMatch>

### block cgi, perl, python
<FilesMatch "\.(cgi|pl|py)$">
Order allow,deny
Deny from all
</FilesMatch>

### block certain file types
### haal een extensie weg als het bestand niet geblokkeerd moet zijn voor zowel mens als bot
<FilesMatch "\.(bak|config|conf|dist|htm|inc|ini|log|sql|txt)$">
Order allow,deny
Deny from all
</FilesMatch>

### do not block robots.txt
<Files robots.txt>
Order allow,deny
Allow from all
</Files>

### x-content-type no sniff
<IfModule mod_headers.c>
Header set X-Content-Type-Options nosniff
</IfModule>

### x-frame same origin prevents clickjacking iframing content
<IfModule mod_headers.c>
Header set X-Frame-Options "SAMEORIGIN"
</IfModule>

### x-xss-protection
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
</IfModule>

### block certain strings after the ? mark in the url
# IF the uri contains http: or https:
RewriteCond %{QUERY_STRING} http\: [OR]
RewriteCond %{QUERY_STRING} https\: [OR]
# OR IF the uri contains [ or ]
RewriteCond %{QUERY_STRING} \[ [OR]
RewriteCond %{QUERY_STRING} \] [OR]
# OR IF the uri contains <script>
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# OR IF the script trying to set a php globals variable via url
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# OR IF any script is trying to modify a _request variable via url
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
# OR IF the uri contains union
RewriteCond %{QUERY_STRING} UNION [OR]
# OR IF the uri contains double slash
RewriteCond %{QUERY_STRING} // [OR]
# OR IF the request contains /proc/self/environ (lfi hack)
RewriteCond %{QUERY_STRING} proc\/self\/environ [OR]
# OR IF the uri contains asterisk
RewriteCond %{QUERY_STRING} \*
# THEN deny the request 403
RewriteRule ^.*$ - [F,L]

Nu over de bots die je website benaderen. Een bot kan zich voordoen als echte mens door de User Agent in de bot hetzelfde te maken als een normale browser. Je kan dus nooit onderscheid maken tussen bot en mens. Dit gezegd hebbende gebruiken de "nette zoekmachines" een herkenbare User Agent string zodat je die wel of niet kan uitsluiten. Maar het gaat juist om die honderden vervelende bots die je niet op je website wilt hebben. Hiervan zijn lange lijsten te vinden op internet. Je kan bots in bestand .htaccess als volgt uitsluiten om te voorkomen dat ze op jouw website komen.
Code: 
### block "bad bots"
SetEnvIfNoCase User-Agent "\s[COLOR=#24292E][FONT=ui-monospace]YLT[/FONT][/COLOR]" bad_bot
SetEnvIfNoCase User-Agent "[COLOR=#000000]^b0t$[/COLOR]" bad_bot
SetEnvIfNoCase User-Agent "[COLOR=#000000]^bluefish[/COLOR]" bad_bot
  # -> zie linkje hieronder voor een lijst van 1360 bots
  # -> die op dezelfde manier als deze voorbeelden hier moeten staan
SetEnvIfNoCase User-Agent "[COLOR=#000000]Zoom\.Mac[/COLOR]" bad_bot
SetEnvIfNoCase User-Agent "[COLOR=#000000]ZoteroTranslationServer[/COLOR]" bad_bot
SetEnvIfNoCase User-Agent "[COLOR=#000000]ZyBorg[/COLOR]" bad_bot

<Limit GET POST>
order allow,deny
allow from all
deny from env=bad_bot
</Limit>

Lijst met bots (klik) maar er zijn er veel meer. Je zal de vele lijsten op internet zelf moeten samenvoegen en dan telkens updaten zodat de lijst actueel blijft.

Afijn, bots uitsluiten is een dingetjes wat je dagelijks moet gaan bijhouden omdat dit dagelijks verandert. En elke dag zal je er een paar missen die wel de bestanden kunnen lezen. Zoals ik in post #3 al aangaf, het heeft geen nut om bots te weren van je website en eigenlijk heeft dit niets met beveiliging te maken. Het heeft meer te maken met privacy, bijvoorbeeld omdat je foto's met persoonlijke gegevens op je website hebt staan maar het is bekend dat dit niet mag.
 
Laatst bewerkt:
Om een lang verhaal kort samen te vatten:

Je kan je eigenlijk afvragen wat het verschil is tussen een bot en een mens.
Een bot werkt geautomatiseerd, dus als iemand die documenten wilt downloaden dan moet je diegene laten bewijzen dat diegene een mens is.
Dit kan via een authenticatie, via een inlogsysteem. Of via een verificatie via een e-mailadres. Misschien zou Re-Captcha wel kunnen helpen.

Misschien heeft de topicstarter wel een inlogsysteem op zijn site waarmee mensen kunnen inloggen.
Misschien is het ook handig om wat meer context te geven over de documenten. Misschien speelt er veel meer om rekening mee te houden. Misschien zelfs met GDPR of AVG.
We geven graag advies aan anderen om te voorkomen dat iemand het foute pad inslaat.

Dus als Leifoet wat meer details kan geven?
 
Laatst bewerkt:
leifoet. Even terug naar jouw vragen van #7

RE: sorry, geraak (meer dan een beetje) overdonderd (... mijn te beperkte bagage ?!)
Iedereen heeft kennis op zijn/haar eigen niveau, het is aan de helpers om dit goed in te schatten.

RE: Betreft eigen pagina's => besmetting ?
Vergeet het woord 'besmetting'. Dan zou je nu vervelende dingen op je website hebben, ik denk dat dit niet zo is?

RE: als bepaalde pagina's niet zichtbaar zijn in bots, zijn ze dan veiliger (?)
Zichtbaarheid voor bots heeft met privacy te maken en niets met beveiliging. Het is aan jou om geen privacy gevoelige teksten/foto's voor iedereen zichtbaar op de website te zetten.

RE: is verbergen nu wel of niet mogelijk ?
In principe wel maar dan ben je dagelijks een lijst van honderden bots aan het updaten. En elke bot kan zich voordoen als normale browser (als mens) dus het heeft totaal geen nut om hier tijd aan te besteden.

RE: Wat wordt bedoeld met een onmiddellijke toegang geven aan het bestandsysteem
Niemand kan van buitenaf bestanden aanpassen, toevoegen of verwijderen.... maar .... helaas is dit in de praktijk niet waar. Hackers kunnen op vele manieren proberen door te dringen bij jouw website, of buiten jouw schuld, bij de provider. Je kunt veel doen maar waterdicht wordt het nooit.

RE: Heeft regex te maken met 'verbergen' ?
Met een regex kan je een "expressie" maken om bijvoorbeeld bestanden te selecteren. Expressie *\.doc$ filtert alle bestanden die eindigen op .doc Na de expressie regel kan je iets gaan doen met de geselecteerde mappen en/of bestanden. Er zijn heel veel mogelijkheden waar je met regex op een slimme manier iets kan filteren. De regex is geen beveiliging, het gaat er om wat je na de regex regel gaat doen.

Ander voorbeeld van een regex: In een webshop zijn (waarom is onbekend) in de live omgeving "test product pagina's" terecht gekomen met de namen: a-producct.html, b-product.html, c-product.html, enz. De url wordt met een regex gefilterd en als de url een testpagina is dan wordt men doorgestuurd naar pagina "producten".
Code: 
RewriteRule ^[a-z]\-product\.html$  https://www.example.nl/producten [L,R=301]
 
Laatst bewerkt:
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan