[.htaccess / mod_rewrite] SWF beveiligen

[Verwijderd]

Mensen, Ik kom er niet uit. Ik heb een website die op het moment meer dan 20GB dataverkeer per maand gebruikt. En.. het wordt steeds meer.

Nu wil ik zorgen dat alleen de .swf vanaf mijn www. te bezoeken zijn. Echter roep ik ze daar zelf op via: webgames.dom.ext

Ik gebruik dit voor mijn images:

code:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^http://ad.org(/)?.*$     [NC]
RewriteCond %{HTTP_REFERER} !^http://add.net(/)?.*$     [NC]
RewriteCond %{HTTP_REFERER} !^http://www.ad.org(/)?.*$     [NC]
RewriteCond %{HTTP_REFERER} !^http://www.add.net(/)?.*$     [NC]
RewriteRule .*\.(gif|jpg|jpeg|bmp)$ http://www.ad.org [R,NC]

Nu dacht ik.. Ik kan natuurlijk ook het zelfde blijven gebruiken. maar dan gewoon bij de laatste regel swf toevoegen.
Probleem: Onder mozilla kan ik netjes de swf bestanden uitlezen. MAar onder IE kan ik geen swf meer openen. Voordeel: er is geen hotlinking meer mogelijk. Nadeel. Ik kan via m'n eigen site nu ook weinig.

Nu zag ik dat het probleem bij swf is dat hij geen http_referer mee stuurt. En dat je dan mod_rewrite moet hebben om het via de apache te laten blocken. Euhm Probleem. Ik kom wel bij m'n .htaccess maar niet bij de apache.conf file.

Ik heb op google gezocht. En stom genoeg kwam ik daar over al tegen wat ik zelf dat dat ook wel mogelijk zou zijn. Gewoon mijn code die ik hierboven heb neergezet + daarbij swf code. Ik kwam ook een aantal andere tegen waarbij de laatste regel niet op: [R,NC] eindigde maar op: [R]+ maar ja.. dan werkte hij helemaal nergens meer.

Weet iemand een mooie oplossing voor mij? Ga a.u.b niet beginnen met rename van files. het gaat om meer dan 200 bestanden en het worden er op tenduur alleen maar meer.

[GlowMouse]

Als er geen referer meegestuurd wordt is het knap lastig om dat te blokkeren. Dan zou je op je website bij moeten houden wie er geweest is, en dat via een showswf.php?swf=.... controleren en de swf doorsturen.

[Verwijderd]

GlowMouse schreef op 04 juni 2004 @ 23:07:
Als er geen referer meegestuurd wordt is het knap lastig om dat te blokkeren. Dan zou je op je website bij moeten houden wie er geweest is, en dat via een showswf.php?swf=.... controleren en de swf doorsturen.

maar dan blijf je toch het probleem houden dat mensen het echte link kunnen vinden? en die dan kunnen gebruiken op hun eigen site. Of begrijp ik het nu verkeerd?

Naja of IE moet gewoon een keer wat netter omgaan zodat ze ook de basis rules gebruiken. Zoals mozilla, firefox, netscape, konquere etc..

[ Voor 15% gewijzigd door Verwijderd op 04-06-2004 23:09 ]

[NMe]

Verwijderd schreef op 04 juni 2004 @ 23:08:
maar dan blijf je toch het probleem houden dat mensen het echte link kunnen vinden? en die dan kunnen gebruiken op hun eigen site. Of begrijp ik het nu verkeerd?

Niet als je de SWF file opent via PHP, en dan streamt. Dan zou ik wel zorgen dat de links naar de swf files in een database zitten, zoiets als dit:
Tabel swf_files: id, hash, link
In hash komt een hash van het id, zodat het niet makkelijk te vinden is. Dan kun je je de pagina openen via showswf.php?swf=29ah40392hf oid.

Dus kort:
1) HTTP_REFERER checken en 403 error oproepen als het niet klopt.
2) Bij goede referer de hash uit de querystring opzoeken in de database.
3) Uit het veld link in de database de goede filenaam ophalen.
4) SWF header setten (mime-type), file openen en meteen streamen.

[Erkens]

NMe84 schreef op 04 juni 2004 @ 23:20:
[...]

Niet als je de SWF file opent via PHP, en dan streamt. Dan zou ik wel zorgen dat de links naar de swf files in een database zitten, zoiets als dit:
Tabel swf_files: id, hash, link
In hash komt een hash van het id, zodat het niet makkelijk te vinden is. Dan kun je je de pagina openen via showswf.php?swf=29ah40392hf oid.

waarom wilt iedereen alles in een database zetten
gewoon in een directory plaatsen waar geen public read rechten zijn (buiten de webdir bijvoorbeeld)
en dan de filename opgeven als argument, checken of die file aanwezig is in die directory en gaan met de swf'files
(let even op eventuele slashes die meegegeven kunnen worden, zodat er geen files buiten die dir opgevraagd kunnen worden)

[NMe]

Erkens schreef op 04 juni 2004 @ 23:26:
waarom wilt iedereen alles in een database zetten
gewoon in een directory plaatsen waar geen public read rechten zijn (buiten de webdir bijvoorbeeld)
en dan de filename opgeven als argument, checken of die file aanwezig is in die directory en gaan met de swf'files
(let even op eventuele slashes die meegegeven kunnen worden, zodat er geen files buiten die dir opgevraagd kunnen worden)

Mjah, das inderdaad nog beter. Maar het idee van streamen blijft.

[CyBeR]

NMe84 schreef op 04 juni 2004 @ 23:20:
[...]

Niet als je de SWF file opent via PHP, en dan streamt. Dan zou ik wel zorgen dat de links naar de swf files in een database zitten, zoiets als dit:
Tabel swf_files: id, hash, link
In hash komt een hash van het id, zodat het niet makkelijk te vinden is. Dan kun je je de pagina openen via showswf.php?swf=29ah40392hf oid.

Als je 't dan per se in een database wilt proppen (wat imo geen goed idee is, maar ok 't is 'in' ofzo) dan ben je hier al meteen niet goed bezig. Waarom heb je een id veld? Je hash is ook uniek*, dus die kun je als primary key gebruiken. Scheelt weer.

_{*) Niet helemaal, maar de kans bij MD5 en SHA1 hashes dat je 2 verschillende files hebt met dezelfde hash is onnoemelijk klein}

[NMe]

CyBeR schreef op 04 juni 2004 @ 23:31:
[...]


Als je 't dan per se in een database wilt proppen (wat imo geen goed idee is, maar ok 't is 'in' ofzo) dan ben je hier al meteen niet goed bezig. Waarom heb je een id veld? Je hash is ook uniek*, dus die kun je als primary key gebruiken. Scheelt weer.

_{*) Niet helemaal, maar de kans bij MD5 en SHA1 hashes dat je 2 verschillende files hebt met dezelfde hash is onnoemelijk klein}

Je kan inderdaad de hash als PK nemen, maar hoe bepaal je dan de waarde van de volgende hash die je toevoegt?

[Erkens]

NMe84 schreef op 04 juni 2004 @ 23:33:
[...]

Je kan inderdaad de hash als PK nemen, maar hoe bepaal je dan de waarde van de volgende hash die je toevoegt?

waarom een hash maken van het id
beetje onzinnig, zeker als je die _ook_ saved in je table, helemaal nergens voor nodig

[CyBeR]

NMe84 schreef op 04 juni 2004 @ 23:33:
[...]

Je kan inderdaad de hash als PK nemen, maar hoe bepaal je dan de waarde van de volgende hash die je toevoegt?

Ehm? Door een hash te maken van de file? Waar wilde jij een hash van maken dan?

[NMe]

Erkens schreef op 04 juni 2004 @ 23:34:
waarom een hash maken van het id
beetje onzinnig, zeker als je die _ook_ saved in je table, helemaal nergens voor nodig

Hash maken van het ID is wel nodig, dan kun je niet zomaar het volgende filmpje opvragen in de adresbalk, wat weer garandeert dat de mensen het via je site bekijken.
Maar waarom ik die hash nou op wou slaan in een database moet je mij niet vragen. Laten we het op een kort moment van verstandsverbijstering gooien. (In de woorden van onze geliefde prinses: ik was een beetje dom )

[Erkens]

CyBeR schreef op 04 juni 2004 @ 23:36:
[...]


Ehm? Door een hash te maken van de file? Waar wilde jij een hash van maken dan?

In hash komt een hash van het id, zodat het niet makkelijk te vinden is.

NMe84 schreef op 04 juni 2004 @ 23:38:
[...]

Hash maken van het ID is wel nodig, dan kun je niet zomaar het volgende filmpje opvragen in de adresbalk, wat weer garandeert dat de mensen het via je site bekijken.
Maar waarom ik die hash nou op wou slaan in een database moet je mij niet vragen. Laten we het op een kort moment van verstandsverbijstering gooien. (In de woorden van onze geliefde prinses: ik was een beetje dom )

ah, maar dan kan je net zogoed de filename gebruiken, anders dan via die php file kom je er toch niet

[ Voor 52% gewijzigd door Erkens op 04-06-2004 23:40 ]

[CyBeR]

Erkens schreef op 04 juni 2004 @ 23:38:
[...]


[...]

Oh, niet gezien. Zo vreemd waarschijnlijk dat ik er overheen gelezen had. Een hash maken van het id is gewoon _raar_

[NMe]

CyBeR schreef op 04 juni 2004 @ 23:40:
Oh, niet gezien. Zo vreemd waarschijnlijk dat ik er overheen gelezen had. Een hash maken van het id is gewoon _raar_

Laten we weer on-topic gaan voordat we dit topic helemaal verknallen. Ik denk dat TS wel vooruit kan met mijn plan en het in acht nemen van jullie verbeteringen.

[Gerco]

Als extra beveiliging zou je nog links kunnen maken die maar een bepaalde tijd werken. Dat kan heel eenvoudig door de huidige tijd plus een interval (1 uur ofzo) te coderen en mee te geven aan je showswf.php script.

Dit kan deze tijd weer decoderen en kijken of die inmiddels is verstreken. Als je een handige codering gebruikt is het best moeilijk dat systeem te breken.

Voordeel hierbij is dat je geen eenmalige ids oid in de database hoeft op te slaan, een zwakheid is dat je een omkeerbare codering moet gebruiken voor de tijd.

[brokenp]

Het laatst genoemde nadeel is vrij eenvoudig op te lossen door het in een database op te slaan
Moeilijk te raden ID | timestamp | file

Het is belangrijk dat je ID moelijk te raden is, evt een hash van de timestamp+ filename ofzo.

[Gerco]

Als je die timestamps gaat opslaan moet je wel oppassen dat je de niet gebruikte regelmatig opruimt. Anders kan je database aardig oplopen, zeker bij de hoeveelheid traffic waar de TS het over heeft.

Het aantal ongebruikte stamps is wel minimaal te houden door op je "selecteer een swf" pagina te linken naar php scripts die de swf embedden met een timestamp.

De sites die je links jatten zullen ws niet naar zo'n pagina willen linken en als ze dat wel doen, heeft de bezoeker iig gezien waar die swf vandaan komt.

[Grijze Vos]

CyBeR schreef op 04 juni 2004 @ 23:31:
_{*) Niet helemaal, maar de kans bij MD5 en SHA1 hashes dat je 2 verschillende files hebt met dezelfde hash is onnoemelijk klein}

Hehe, dat had ik ook gedaan bij mn usersessions. Geen dubbele waarden check erin gezet. Toen had opeens een clanmember adminrechten die hij niet hoorde te hebben. Was wel grappig.

ID's zijn wel handig, je kunt een tabel optimizen, en de dbase ze in de goeie volgorde laten opslaan. Dan is het zoeken wat simpeler.

[Verwijderd]

Ok ik ben hierover een aantal weken geleden begonnen en toen is er vanalles gebeurd waardoor het even heeft stil gelegen

Maar goed. Het idee blijft nog steeds. En ik heb / probeer het nu anders op te lossen.

Ik zeg tegen pagina 1:

code:

include("http://webgames.domeinnaam.ext/start.php");

Dan zeg ik in start.php

code:

mysql_connect('******', '******', '******');
mysql_select_db('******');
$result = mysql_query("SELECT * FROM webgames WHERE id={$_GET['sid']}") or die(mysql_error());
$row = mysql_fetch_array($result);

echo $row['html'];

naja ik had datdus lalemaal werkend. Alleen het beveiligen nog steeds niet. Reden dat ik het zo deed is omdat ik dan een bestand rechtstreeks bij de swf heb geplaatst.

Maar.... het werkt uiteraard nog steeds niet. Kan ik niet aangeven in een .htaccess dat de bestanden alleen geopend mogen worden met behulp van: start.php? en anders maar pech?

[Gomez12]

Als je nou gewoon de dir van je swf'jes verandert??? en listing onmogelijk maakt. Dit voorkomt het eerste hotlinking. Alle bestaande hotlinks werken niet meer.

En op jouw pagina's ga je dus alleen maar downloaden via die download.php die gewoon met een fopen een swf file leest uit de dir en deze echo't naar de gebruiker.

Dit is allemaal ervanuit gaande dat je swfjes op een andere host staan dan je php files. Want hiermee kunnen mensen de files nog steeds hotlinken, maar dan moeten ze wel het exacte pad weten wat dus via php niet naar buiten gegeven wordt. Dus als het goed is weet niemand het complete pad. Deze methode kost je tussen twee servers ( 1 file en een php server wel 3x data :
1x data fopen van fileserver -> php (1x upload fileserver + 1x download php server )
1x data van php server -> client ( 1x upload php server )
)

Anders gewoon je swfjes gewoon uit de webroot halen en dan streamen van local host. Is het mooiste en het handigste, want dan kan niemand behalve je php / ftp sessie er nog bij.