[php]Een goede manier om een .js te beveiligen

[Verwijderd]

jaja ik weet wat 90% van GOT denkt als ze zo'n titel lezen
RTFM STFU N00b lolo...........

Maar oke ik wil dat en waarom ?
Nou ik heb een cms waarvan ik de source niet gelijk kado wil geven en nou kan ik cm5 enzo gebruiken in javascript om het te coderen maar alles wat te coderen is is ook te encoden.

Nou dacht ik eerst dat het wel gewoon met HTTP_REFER (uhh) te doen zal zijn maar ja als je dan het .js bestand na het loaden van de pagina laad krijg je volgens mij ook gewoon een go van HTTP_REFERER.
Daarna dacht ik dat het misschien wel met sesions te doen zal zijn;
Dus een session starten op de pagina die het .js file laadt daarna voor die sessie checken in het js file (ook met php dus) en na het vinden van de sesie de source echo'en en de sessie gelijk destroyen.
Alleen heb ik wat session problemen in php (niet in het scripten hé) en kan het zeker niet de komende twee dagen oplossen.

[ Voor 17% gewijzigd door Verwijderd op 05-05-2003 20:42 ]

[Verwijderd]

nee gaat niet werken.... sorry of je zou netzoals zend je javascript moeten encrypten.. en weet niet of daar mogelijkheden voor zijn, maar sessies gaat niet werken want je moet je javascript code zo ie zo in de output hebben of een include daarvan dus altijd leesbare karacters

[gorgi_19]

Je werkt met clientside output. Zonder clientside output, snapt je browser het niet. Dus alles wat je naar de client stuurt, is te achterhalen.

[Skaah]

Kun je niet gewoon al je code server-side draaien en dan zoveel mogelijk HTML out-putten?

[crisp]

gewoon flink obfuscaten, en geloof me: niemand die dan de moeite meer zal nemen om je code uit te gaan pluizen

[3o3]

je kan het javascriptje toch gewoon laten genereren vanuit een php file...?
of had je dat juist al gedaan?

[gorgi_19]

3o3 schreef op 05 May 2003 @ 23:22:
je kan het javascriptje toch gewoon laten genereren vanuit een php file...?
of had je dat juist al gedaan?

En da's het probleem; die Javascript wil hij juist 'beschermen'

[crisp]

uiteindelijk komt die js toch in de browsercache van de client terecht; koud kunstje om 'm daaruit te vissen...
Er bestaat geloof ik wel een manier om js code te encoderen, waarna het door de browser by het parsen gedecodeerd word. Helaas is dit (uiteraard) IE-only (maar dat zal dat CMS waarschijnlijk ook wel zijn).

gevonden

[ Voor 74% gewijzigd door crisp op 05-05-2003 23:36 ]

[Verwijderd]

check http://www.protware.com/

[Verwijderd]

om over http://www.jimtools.com/tools/javascript-encrypt/ nog maar te zwijgen

[crisp]

Verwijderd schreef op 05 May 2003 @ 23:33:
check http://www.protware.com/

Verwijderd schreef op 05 May 2003 @ 23:37:
om over http://www.jimtools.com/tools/javascript-encrypt/ nog maar te zwijgen

Sorry hoor, maar met beide methoden kan ik nog redelijk eenvoudig de originele js source achterhalen

[KompjoeFriek]

Als er echt geen andere manier is om je code JS-code goed te beveiligen zou ik er op z'n minst alles aan doen om de "steler" het zo moelijk mogelijk te maken.
Dus met andere woorden doe wat Crisp zegt, Je code flink obfuscaten, en dan nog eens gaan Encrypten.
Dat zulle ze niet zo leuk vinde

[Verwijderd]

obfuscaten zal wel het enige preventie middel zijn wat een beetje effectief is.
Maar toch heb ik nog wat met php geprobeerd:
http://www.onssneek.nl/test/test.php
Wie om wie kan de javascript source hiervan te voorschijn krijgen, en hoe ?

offtopic:
Server is niet van mij dus let niet op inhoud van het domein, wanneer de host die weer terugplaatst

[Krooswijk.com]

jij include in je script 'java.php' in mijn temporary internet files komt dus gewoon 'java.htm' terecht met jouw scriptje derin...

JavaScript:

//dit is nou mijn javascript protection :/ 

alert('bla'); 
//goed he :'( 
//Nutteloze shit dus 

[ Voor 39% gewijzigd door Krooswijk.com op 06-05-2003 10:48 ]

[Verwijderd]

Krooswijk.com schreef op 06 May 2003 @ 10:47:
jij include in je script 'java.php' in mijn temporary internet files komt dus gewoon 'java.htm' terecht met jouw scriptje derin...

Oh de temp Internet files folder.
Compleet vergeten Maar wat nou als ik nou het javascript bestand twee keer src dus zo dat bij de eerste keer het javascript gedeelte ge-echod wordt en dat er bij de tweede keer een fake code wordt gegeven ? zo dus
http://www.onssneek.nl/test/test.php
Zou dan het bestand in temporary internet files overschreven worden met de fake code ? (nu dus een leeg bestand).

oh ik heb heb || destroy!="true" gedaan inplaats van && Nou geeft die dus ook de inhoud bij het weergeven van java.php Ik zal het gelijk veranderen.

Dan zal ook even mn instellingen na lopen waarom ik nou geen html bestanden in mijn temp folder terugvindt.

[ Voor 68% gewijzigd door Verwijderd op 06-05-2003 11:46 ]

[3o3]

gorgi_19 schreef op 05 mei 2003 @ 23:25:
[...]

En da's het probleem; die Javascript wil hij juist 'beschermen'

Ik bedoel dus bijvoorbeeld iets als dit;

in je php/html file include je dus een javascript

<SCRIPT LANGUAGE="Javascript" SRC="../js/blaat.js.php"></SCRIPT>

aangezien het niet gaat werken omdat iedereen inderdaad die blaat.js.php kan zien dacht ik wie weet wil het wel met sessie/cookie vlaggetjes. Je wil geen data meegeven in de querystring, maar misschien kan het wel via een sessie:

code:

session_start;
session_register ("JS_flag");
$JS_flag = true; 
echo "<SCRIPT LANGUAGE=\"Javascript\" SRC=\"../js/blaat.js.php\"></SCRIPT>";
$JS_flag = false;

en in je javascript:

code:

<?
    if (!$JS_flag) die("opzoute!");
    else {
?>

// hier je scriptzooi

<? } ?>

heb het niet getest, is een brainwaveje van me. wie weet werkt het nog ook (ben eigenlijk wel benieuwd)? anders gewoon fukalizen met bestaande encrypters. De meeste snuffelaars lopen dan inderdaad al weg.

[Verwijderd]

3o3 schreef op 06 mei 2003 @ 11:56:
[...]


Ik bedoel dus bijvoorbeeld iets als dit;

in je php/html file include je dus een javascript

<SCRIPT LANGUAGE="Javascript" SRC="../js/blaat.js.php"></SCRIPT>

aangezien het niet gaat werken omdat iedereen inderdaad die blaat.js.php kan zien dacht ik wie weet wil het wel met sessie/cookie vlaggetjes. Je wil geen data meegeven in de querystring, maar misschien kan het wel via een sessie:

code:

session_start;
session_register ("JS_flag");
$JS_flag = true; 
echo "<SCRIPT LANGUAGE=\"Javascript\" SRC=\"../js/blaat.js.php\"></SCRIPT>";
$JS_flag = false;

en in je javascript:

code:

<?
    if (!$JS_flag) die("opzoute!");
    else {
?>

// hier je scriptzooi

<? } ?>

heb het niet getest, is een brainwaveje van me. wie weet werkt het nog ook (ben eigenlijk wel benieuwd)? anders gewoon fukalizen met bestaande encrypters. De meeste snuffelaars lopen dan inderdaad al weg.

Zoiets heb ik nou ook
test.php

PHP:

<?
session_name("javascript"); 
$doe_javascript = true
session_start();
session_register("doe_javascript");
?>
<script src="java.php?destroy=false"></script>
<script src="java.php?destroy=true"></script>

java.php

PHP:

<?
session_name("javascript"); 
session_start();
session_register("doe_javascript");
if ($doe_javascript && !$destroy) {
session_unregister('doe_javascript'); 
echo "javascript";
}//if
else {
echo "opzoute !";
}//else
?>

[ Voor 36% gewijzigd door Verwijderd op 06-05-2003 12:13 ]

[TeeDee]

Kan je niet met caching properties werken?
Dus zodat ie niks in de Temp files stopt?

[Verwijderd]

TeeDee schreef op 06 May 2003 @ 12:11:
Kan je niet met caching properties werken?
Dus zodat ie niks in de Temp files stopt?

Nee want bestanden worden altijd gecached


Ik heb het nog een beetje veranderd zoals je kan zien komt
<script src="java.php"></script>
twee keer voor, bij de tweede keer wordt er echter een leeg java.php bestand weergegeven deze overschijft volgens mij het eerste gecached java.php bestand in de temp internet files directory.

TEST.PHP

PHP:

<?
session_name("javascript"); 
$doe_javascript =true;
session_start();
session_register("doe_javascript");
?>
<script src="java.php"></script>
<script src="java.php"></script>

JAVA.PHP

PHP:

<?
session_name("javascript"); 
session_start();
session_register("doe_javascript");

    if ($doe_javascript && !$destroy) {
        $destroy=true;
        session_register("destroy");
        session_unregister('doe_javascript'); 
        echo ("javascript");
    }//if
        else {
        session_unregister('destroy'); 
        echo "fake_source=true;";
        
    }//else
?>

Dus wie kan nou nog de javascript source tevoorschijn halen ?
http://www.onssneek.nl/test/test.php

[ Voor 12% gewijzigd door Verwijderd op 06-05-2003 12:34 ]

[Verwijderd]

Oh shit de server is down.
En weer online, de host heeft toevallig tegelijkertijd wat problemen die nou opgelost zouden moeten zijn.

[ Voor 54% gewijzigd door Verwijderd op 06-05-2003 13:10 ]

[3o3]

kijk, het werkt dus nog ook! damn wat een geniale oplossing eigenlijk!
ga deze oplossing zelf ook maar es implementeren in vervolg!

[Verwijderd]

3o3 schreef op 06 mei 2003 @ 13:13:
kijk, het werkt dus nog ook! damn wat een geniale oplossing eigenlijk!
ga deze oplossing zelf ook maar es implementeren in vervolg!

hey ik heb het bedacht ik wil eerst geld zien
maar serieus javascript is clientside er moet toch een manier om de javascript source nog tevoorschijn te krijgen ?
Oftewel juich niet te vroeg

[crisp]

//dit is nou mijn javascript protection fase 2

alert('Take 2. Wie oh Wie kan nu nog bij de javascript source komen?');
//goed he
//Nutteloze shit dus ik dacht dat dit nou niet meer in de temp internet files map zou moeten komen m

[Verwijderd]

crisp schreef op 06 May 2003 @ 13:22:
[...]

en hoe ?

[.oisyn]

Het heeft geen zin. Als je browser het kan downloaden kun je het zelf ook downloaden (of je browser het nou in een dir zet of niet, je kunt natuurlijk ook zelf de request doen zonder je browser te gebruiken). De enige manier om het te beveiligen is om ervoor te zorgen dat je browser het niet kan downloaden. Maar als ie dat niet kan dan werkt je script ook niet. Met andere woorden: het is onbegonnen werk. Obfuscate je code en hoop gewoon dat niemand er aan zit

[Verwijderd]

.oisyn schreef op 06 May 2003 @ 13:28:
Het heeft geen zin. Als je browser het kan downloaden kun je het zelf ook downloaden (of je browser het nou in een dir zet of niet, je kunt natuurlijk ook zelf de request doen zonder je browser te gebruiken).

Zo'n request gaat niet werken omdat een sessie nodig is die door de browser wordt aan gemaakt, toch.

Met andere woorden: het is onbegonnen werk. Obfuscate je code en hoop gewoon dat niemand er aan zit

Maar je kan het wel zo moeilijk mogelijk maken veel mensen zullen op dit moment de source ook niet te pakken kunnen krijgen en als CRISP even vertelt hoe hij dat gedaan heeft is daar misschien ook weer tegen te doen
En daar achter is natuurlijk ook een Obfuscatte code achter te zetten.

[crisp]

Verwijderd schreef op 06 May 2003 @ 13:27:
[...]

en hoe ?

je hebt register_globals op ON staan

--> http://www.onssneek.nl/test/java.php?doe_javascript=true

[terrapin]

Ook zonder register_globals is het nog heel erg makkelijk om de source van het script nog te krijgen...

[Verwijderd]

crisp schreef op 06 May 2003 @ 13:37:
[...]

je hebt register_globals op ON staan

--> http://www.onssneek.nl/test/java.php?doe_javascript=true

Vals speler, even misbruik maken van mijn geposte php source
Ik heb de variabellen even hernoemd, dus dan lukt het bovenste truukje niet meer

maar dat betekend ook dat tot nu toe nog niemand de source te pakken heeft kunnen krijgen (zonder vals te spelen dan)

terrapin schreef op 06 mei 2003 @ 13:45:
Ook zonder register_globals is het nog heel erg makkelijk om de source van het script nog te krijgen...

Vertel dan ook gelijk even hoe, en post dan ook even de javascript source die je nu te zien krijgt.

[ Voor 25% gewijzigd door Verwijderd op 06-05-2003 13:47 ]

[terrapin]

//dit is nou mijn javascript protection fase 3 alert('Take 3. Wie oh Wie kan
nu nog bij de javascript source komen?'); //goed he //Nutteloze shit dus,
.global var even opgelost m

Javascript uit zetten in browser, en in ander window java.php openen

(en dan wel weer javascript aanzetten voor tweakers )

[ Voor 13% gewijzigd door terrapin op 06-05-2003 13:51 ]

[Verwijderd]

he ja zonder javascript kun je het topic niet zien in tweakers,alleen de quick reply optie

Maar ik dacht dat php sesies alleen voor het browser window gelden waarin ze zijn geopend ?
Dat zal dus wel niet maar het kan volgens mij wel.. zal het opzoeken.

[terrapin]

Hum ja tis beetje vaag, eerst lukte het in mozilla, toen weer niet, maar in lynx werkt het iig zonder problemen

Maar je source is altijd te ontdekken, desnoods met een speciale debug versie van mozilla of zo..

[.oisyn]

Verwijderd schreef op 06 mei 2003 @ 13:33:
[...]

Zo'n request gaat niet werken omdat een sessie nodig is die door de browser wordt aan gemaakt, toch.

als je browser het kan kan jij het toch ook?
Desnoods draai je een packetsniffer en onderschep je dus gewoon het verkeer. Daar kun je ook de javascript source uit vissen

[crisp]

//dit is nou mijn javascript protection fase 3
alert('Take 3. Wie oh Wie kan nu nog bij de javascript source komen?');
//goed he
//Nutteloze shit dus, .global var even opgelost m

idd, packetsniffer

edit... shit te laat

[ Voor 11% gewijzigd door crisp op 06-05-2003 14:02 ]

[.oisyn]

code:

//dit is nou mijn javascript protection fase 3 :/ 

alert('Take 3. Wie oh Wie kan nu nog bij de javascript source komen?'); 
//goed he :'( 
//Nutteloze shit dus, .global var even opgelost m

geen packet sniffer hier, gewoon met internet explorer de pagina in z'n geheel opgeslagen

[ Voor 21% gewijzigd door .oisyn op 06-05-2003 14:03 ]

[Verwijderd]

.oisyn schreef op 06 May 2003 @ 13:59:
Desnoods draai je een packetsniffer en onderschep je dus gewoon het verkeer. Daar kun je ook de javascript source uit vissen

Elke beveiliging is te kraken maar een goede moelijker dan een makkelijke.
Misschien is het niet te verkomen dan 1% de source te pakken krijgt maar het is wel te verkomen dat 100% de source te pakken krijgt.

En bij een niet actieve sessie wordt een valse code geprint veel mensen zullen er dan ook vanuit gaan dat dat de echte is en dus niet met packet sniffers aan komen zetten of javascript uit zetten in hun browser.

[ Voor 21% gewijzigd door Verwijderd op 06-05-2003 14:07 ]

[.oisyn]

Er hoeft er maar 1 te zijn die je javascript ripped en online zet, en vervolgens kan het zonder moeite verspreid worden

[Verwijderd]

.oisyn schreef op 06 May 2003 @ 14:02:
geen packet sniffer hier, gewoon met internet explorer de pagina in z'n geheel opgeslagen

Dat is zo op te lossen:
IE vraagt java.php bij het opslaan opnieuw van de server op, dus als ik na het openen van java.php door de browser java.php laat overschrijven door niks dan zou er een leeg bestand worden opgeslagen...toch.
Zal het gelijk proberen

[ Voor 21% gewijzigd door Verwijderd op 06-05-2003 14:14 ]

[.oisyn]

Mja, da's leuk, dan kan iemand maar 1 keer je pagina zien. En als er wat mis gaat waardoor de file opnieuw gerequest wordt kun je 'm dus niet eens meer zien. Hoezo, user friendly

[sirdupre]

Ik ben eigenlijk ook wel benieuwd waarom je bang bent dat mensen je code gaan jatten.... zo revolutonair zal ie toch ook wel weer niet zijn.... En het is áltijd te onderscheppen. Als je het echt persé beveiligd wilt hebben moet je maar wachten tot Palladium wereldwijd is doorgevoerd.

[.oisyn]

En het is niet te hopen dat dat ooit gebeurd

[sirdupre]

dat ben ik met je eens .
De topicstarter kan het beste kijken of ie met een simpele beveiliging niet tevreden kan zijn (dan kunnen alleen noobs het niet krijgen) of kijken of er geen alternatief voor javascript is. Veel meer keus heeft ie denk ik.

[crisp]

crisp schreef op 05 mei 2003 @ 23:31:
...
Er bestaat geloof ik wel een manier om js code te encoderen, waarna het door de browser by het parsen gedecodeerd word. Helaas is dit (uiteraard) IE-only (maar dat zal dat CMS waarschijnlijk ook wel zijn).

gevonden

nog even mezelf quoten dan maar?

[Verwijderd]

SirDupre schreef op 06 mei 2003 @ 14:15:
Ik ben eigenlijk ook wel benieuwd waarom je bang bent dat mensen je code gaan jatten.... zo revolutonair zal ie toch ook wel weer niet zijn.... En het is áltijd te onderscheppen. Als je het echt persé beveiligd wilt hebben moet je maar wachten tot Palladium wereldwijd is doorgevoerd.

Natuurlijk is het geen wereld wonder ik maar voel er weinig voor om mijn werk zo makkelijk weg te geven.

.oisyn schreef op 06 May 2003 @ 14:15:
Mja, da's leuk, dan kan iemand maar 1 keer je pagina zien. En als er wat mis gaat waardoor de file opnieuw gerequest wordt kun je 'm dus niet eens meer zien. Hoezo, user friendly

Misschien heb ik het niet perfect uitgelegd
maar boven aan test.php zet ik iets van copy("iets.php","java.php");
Waardoor het bestand java.php dus wordt gemaakt.
En op de onderste regel van java.php zet ik dan iets van
unlink("java.php");
copy("dummy.php","java.php");
Waardoor die na het uitvoeren zichzelf verwijderd.
En zichzelf vervangt door dummy.php, het bestand wat IE daarna op gaat slaan.
hierdoor is het volgens mij ook niet meer mogelijk om de source te zijn te krijgen wanneer je javascript uitgeschakeld.

[ Voor 13% gewijzigd door Verwijderd op 06-05-2003 14:32 ]

[sirdupre]

Ik vind het wel een erg creatieve oplossing met dat kopiëren hoor, maar ik vraag me af of dat goed gaat als je veel hits tegelijk gaat krijgen..... dan wordt het bestand gekopieerd terwijl het al bestaat, of verwijderd terwijl een andere client nog bezig is het op te halen.
Wat is er tegen het encoden en de code zo idioot opmaken dat het vrij ongegrijpelijk is .
Oh en nog iets, als het vrij uitgebreidde code is is het waarschijnlijk niet aantrekkelijk om te jatten, omdat het toch bij jouw site hoort en dan zou iemand dus je complete site moeten jatten of de code zo drastisch gaan wijzigen dat ie net zo goed zelf iets had kunnen maken.

[Verwijderd]

SirDupre schreef op 06 May 2003 @ 14:34:
Ik vind het wel een erg creatieve oplossing met dat kopiëren hoor, maar ik vraag me af of dat goed gaat als je veel hits tegelijk gaat krijgen..... dan wordt het bestand gekopieerd terwijl het al bestaat, of verwijderd terwijl een andere client nog bezig is het op te halen.

maar een CMS wordt gelukkig niet door zoveel mensen tegelijk gebruikt dus veel hits zal het wel niet op het zelfde moment krijgen.

SirDupre schreef op 06 May 2003 @ 14:34:
Wat is er tegen het encoden en de code zo idioot opmaken dat het vrij ongegrijpelijk is .
Oh en nog iets, als het vrij uitgebreidde code is is het waarschijnlijk niet aantrekkelijk om te jatten, omdat het toch bij jouw site hoort en dan zou iemand dus je complete site moeten jatten of de code zo drastisch gaan wijzigen dat ie net zo goed zelf iets had kunnen maken.

Encode van het javascript kan ook nog altijd tesamen gaan met deze 'beveiliging' gaan

De server is weer even down maar dat is als het goed is zo opgelost. Anders bel ik het hosting bedrijf weer want ookal is domein niet van mij dit is geen service.
(De host heeft sinds vrijdag avond problemen en daardoor is alles van de server gewist maar ze hebben beloofd de backups vandaag terug te zetten dat zal de down time zo nu en dan wel verklaren)

[ Voor 16% gewijzigd door Verwijderd op 06-05-2003 14:41 ]

[crisp]

download MS script encoder
voorbeeldje

[.oisyn]

Verwijderd schreef op 06 May 2003 @ 14:26:

Misschien heb ik het niet perfect uitgelegd
maar boven aan test.php zet ik iets van copy("iets.php","java.php");
Waardoor het bestand java.php dus wordt gemaakt.
En op de onderste regel van java.php zet ik dan iets van
unlink("java.php");
copy("dummy.php","java.php");
Waardoor die na het uitvoeren zichzelf verwijderd.
En zichzelf vervangt door dummy.php, het bestand wat IE daarna op gaat slaan.
hierdoor is het volgens mij ook niet meer mogelijk om de source te zijn te krijgen wanneer je javascript uitgeschakeld.

Dan nog blijft mijn argument over het 'misgaan' staan. En IE download volgens mij de pagina gewoon opnieuw bij het opslaan, waardoor het dus ook gelijk nutteloos wordt
En idd, je kunt er donder op zeggen dat dit fout gaat bij meerdere hits tegelijk.

- Client 1 doet een request naar test.php
- iets.php wordt gekopieerd naar java.php
- Client 2 doet een request naar test.php
- iets.php wordt (opnieuw) gekopieerd naar java.php
- Client 1 doet een request naar java.php
- java.php wordt verwijderd en dummy.php komt ervoor in de plaats
- Client 2 doet een request naar java.php
- Client 2 krijgt het verkeerde bestand terug

En als je site al niet zoveel hits krijgt dan hoef je dus ook niet zo moeilijk te doen om het te beveiligen, aangezien het aantal potentiele rippers aanzienlijk kleiner is. Bovendien, waarom zou iemand het willen rippen als het de helft van de keren niet werkt omdat er dan steeds toevallig meerdere hits zijn?

[Verwijderd]

Encode tesamen met dit php session gebeuren zal wel aardig fool proof zijn.

Deze manieren lukken nou in ieder geval niet meer:

• "view source"
• het src bestand apart downloaden
• Voor 'pagina opslaan' kiezen in je browser
• javascript uitschakelen in je browser
• In je Temp internet files dir kijken.

Wat wel lukt is dus een packed sniffer.

[Verwijderd]

.oisyn schreef op 06 mei 2003 @ 14:52:
En als je site al niet zoveel hits krijgt dan hoef je dus ook niet zo moeilijk te doen om het te beveiligen, aangezien het aantal potentiele rippers aanzienlijk kleiner is. Bovendien, waarom zou iemand het willen rippen als het de helft van de keren niet werkt omdat er dan steeds toevallig meerdere hits zijn?

Een cms is dus een Content Mangament System de hits hiervan zijn dus != aan de hits op de site zelf.
Want alleen de mensen die de site beheren (een handje vol) zullen toegaan hebben tot de CMS dus hits op percies het zelfde moment (en dan heb ik het dus over micro secondes) zullen verwaarloosbaar zijn.

Daarnaast ook al zou je zo iets gebruiken op een pagina met 1000+ hits per dag de kans dat het dan fout gaat blijft ontzettend klein omdat het over milli secondens gaat.

- Client 1 doet een request naar test.php
- iets.php wordt gekopieerd naar java.php
- java.php wordt verwijderd en dummy.php komt ervoor in de plaats
- Client 2 doet een request naar test.php
- iets.php wordt (opnieuw) gekopieerd naar java.php
- java.php wordt verwijderd en dummy.php komt ervoor in de plaats
- Client 1 doet een request naar java.php
- java.php wordt verwijderd en dummy.php komt ervoor in de plaats
- iets.php wordt (opnieuw) gekopieerd naar java.php
- java.php wordt verwijderd en dummy.php komt ervoor in de plaats
- Client 2 doet een request naar java.php
- Client 2 krijgt het verkeerde bestand terug
- iets.php wordt (opnieuw) gekopieerd naar java.php
- java.php wordt verwijderd en dummy.php komt ervoor in de plaats

Dit klopt ook niet helemaal he als de request gedaan is,is de javascript source al gecached en wordt er dus nooit een verkeerd bestand gegeven bij het requesten behalve als het wissen in de micro seconde valt tussen het copieren en uitvoeren van java.php. Dus de werking zou zo verlopen waar het vet gedrukte dus door mij is toegevoegd.

[ Voor 41% gewijzigd door Verwijderd op 06-05-2003 15:03 ]

[sirdupre]

crisp schreef op 06 May 2003 @ 14:48:
download MS script encoder
voorbeeldje

// the secret message is: 'who let the dog out?'

alert('find the secret message hidden as a comment in this file');


ik had toevallig nog een javascript decoder op m'n computer staan .

En bij mij werkte "pagina opslaan" net op die pagina van Rutger Extreme nog wel, nu trouwens niet meer.

[Banpei]

Verwijderd schreef op 06 mei 2003 @ 14:53:
Encode tesamen met dit php session gebeuren zal wel aardig fool proof zijn.

Deze manieren lukken nou in ieder geval niet meer:

• "view source"
• het src bestand apart downloaden
  • Voor 'pagina opslaan' kiezen in je browser
• javascript uitschakelen in je browser
• In je Temp internet files dir kijken.

Wat wel lukt is dus een packed sniffer.

Lukt hier nog steeds

//dit is nou mijn javascript protection fase 4

alert('Take 4. Wie oh Wie kan nu nog bij de javascript source komen?');
//goed he
//Nutteloze shit dus, post even hoe je dit gedaan hebt in het topic op:
//[rml]Rutger extreme in "[ php]Een goede manier om een .js te beve"[/rml]

[crisp]

SirDupre schreef op 06 May 2003 @ 14:58:
[...]

// the secret message is: 'who let the dog out?'

alert('find the secret message hidden as a comment in this file');


ik had toevallig nog een javascript decoder op m'n computer staan .

En bij mij werkte "pagina opslaan" net op die pagina van Rutger Extreme nog wel, nu trouwens niet meer.

aaarrrgggh, wat is het nut van encoders als er ook decoders voor in omloop zijn?

[Verwijderd]

even wachten

[ Voor 92% gewijzigd door Verwijderd op 06-05-2003 15:06 ]

[Verwijderd]

Banpei schreef op 06 May 2003 @ 14:58:
Lukt hier nog steeds

Nou niet meer (hoop ik) ik had perongeluk een oude versie online gezet waardoor het nog mogelijk was.
______________________________________________________________________________

Dus nu bij versie 5 aan belandt. Wie kan nou nog de source tervoorschijn krijgen
http://www.onssneek.nl/test/test.php

offtopic:
Ik hoor hier eigenlijk prijzen aan te verbinden

[sirdupre]

Ik krijg nu geen pop-up en in de statusbalk staat: Gereed, maar met fouten in de pagina.

[Verwijderd]

SirDupre schreef op 06 May 2003 @ 15:20:
Ik krijg nu geen pop-up en in de statusbalk staat: Gereed, maar met fouten in de pagina.

Ik was bezig nieuwe lines te maken in mijn javascript: dus \n maar vergat dat het al geprint werd door php dus moesten het \\n worden
Opgelost dus.

[4VAlien]

wget --mirror http://www.onssneek.nl/test/test.php


//dit is nou mijn javascript protection fase 5

//Ik hou van jam op mijn brood

alert("Take 5:\n Wie oh Wie kan nu nog bij de javascript source komen? \n Who can find my javascript source ? \n"); ^M
//goed he ^M
//Nutteloze shit dus, post even hoe je dit gedaan hebt in het topic op:

//[rml]Rutger extreme in "[ php]Een goede manier om een .js te beve"[/rml]

[Verwijderd]

4VAlien schreef op 06 May 2003 @ 15:31:
wget --mirror http://www.onssneek.nl/test/test.php

Damn wget IK heb nu wat verandert dus $HTTP_REFERER er in gezet lukt het nu nog steeds met wget ? ik kan het zelfs hier helaas niet proberen.

$HTTP_REFERER maakt voor mijn CMS niks uit omdat ze toch altijd een link nodig hebben om er op te komen. Voor andere scripts is het niet echt handig.

[4VAlien]

code:

total 12
-rw-r--r--    1 rene     webdev        368 May  6 15:55 java.php
-rw-r--r--    1 rene     webdev          0 May  6 15:55 javascript.php
-rw-r--r--    1 rene     webdev        106 May  6 15:55 test2.php
-rw-r--r--    1 rene     webdev         45 May  6 15:55 test.php

de code zit nu in java.php, verder geen nieuwe problemen geloof ik

[terrapin]

//dit is nou mijn javascript protection fase 6

//Pindakaas stinkt

alert("Versie 6:\n Wie oh Wie kan nu nog bij de javascript source komen?");

//goed he
//Nutteloze shit dus, post even hoe je dit gedaan hebt in het topic op:

//[rml]Rutger extreme in "[ php]Een goede manier om een .js te beve"[/rml]

Het gaat je toch niet lukken

[ Voor 8% gewijzigd door terrapin op 06-05-2003 15:57 ]

[SoLiS]

//dit is nou mijn javascript protection fase 6 //Pindakaas stinkt alert("Versie 6:\n Wie oh Wie kan nu nog bij de javascript source komen?"); //goed he //Nutteloze shit dus, post even hoe je dit gedaan hebt in het topic op: //[rml]Rutger extreme in "[ php]Een goede manier om een .js te beve"[/rml]

Ik heb eerst http://www.onssneek.nl/test/javascript.php geopend
toen http://www.onssneek.nl/test/java.php en een paar keer op F5 geramd in IE

[sjokki]

Zucht: http://sjokki.ath.cx/kansloos.png
Alles wat binnen komt is te lezen.

[Scarfish]

Verwijderd schreef op 06 May 2003 @ 15:54:
[...]

Damn wget IK heb nu wat verandert dus $HTTP_REFERER er in gezet lukt het nu nog steeds met wget ? ik kan het zelfs hier helaas niet proberen.

$HTTP_REFERER maakt voor mijn CMS niks uit omdat ze toch altijd een link nodig hebben om er op te komen. Voor andere scripts is het niet echt handig.

Maakt toch niet uit. Je kunt de referer toch faken

[Verwijderd]

Dan laat ik het hier bij
terrapin Dat het niet 100% zou lukken wist ook wel.
maar nu is het in iedergeval meer verstopt dan anders, en wie het nou nog tervoorschijn krijgt kan het ook wel zelfs maken
Ik zal de broncodes hier nog wel posten voor de mensen die het intressant vinden of noobs die hier via de search komen met bijvoorbeeld een search string van "javascripts beveiligen rechter muis" .

En misschien is er nog iemand die denkt dat hij/zij het nog kan verbeteren.

[Verwijderd]

Het bestaat dus uit 4 paginas

ten eerste een html pagina die dit bevat:

PHP:

<script src="session_load.php"></script>
<script src="java.php"></script>
<script src="java.php"></script>

Daarna SESSION_LOAD.PHP

PHP:

<?
session_name("javascript"); 
$doe_javascript =true;
session_start();
session_register("doe_javascript");
copy ("java_orgineel.php","java.php");
?>

En JAVA_ORGINEEL.PHP

PHP:

<?
copy ("dummy.php","java.php");
session_name("javascript"); 
session_start();
session_register("doe_javascript");
    if ($doe_javascript && !$destroy) {
        $destroy=true;
        session_register("destroy");
        session_unregister('doe_javascript'); 
        echo ("javascript");
    }//if
session_unregister('destroy'); 
?>

En als laatste DUMMY.PHP

code:

false_code=true;

SESSION_LOAD.PHP wordt ook als javascript geladen om te verkomen dat een sessie aan wordt gemaakt terwijl javascripts zijn uitgeschakeld.

In SESSION_LOAD.PHP wordt de sessie aangemaakt die JAVA_ORGINEEL.PHP nodig heeft om uitgevoerd te worden.

[ Voor 80% gewijzigd door Verwijderd op 06-05-2003 17:13 ]

[SoLiS]

Ik krijg 'm nog steeds op redelijk simpele manier tevoorschijn (dus niet noob-proof)

eerst http://www.onssneek.nl/test/session_load.php intikken in de adresbalk van IE, vervolgens http://www.onssneek.nl/test/java.php intikken en dan een paar keer op F5 drukken.

[Verwijderd]

SoLiS schreef op 06 May 2003 @ 16:15:
Ik krijg 'm nog steeds op redelijk simpele manier tevoorschijn (dus niet noob-proof)

eerst http://www.onssneek.nl/test/session_load.php intikken in de adresbalk van IE, vervolgens http://www.onssneek.nl/test/java.php intikken en dan een paar keer op F5 drukken.

Dit is volgens mij oplossen door een sessie aan te maken die alleen in het huidige window geldt als dat kan (dacht het wel). Daarnaast druk je een paar keer op F5 omdat je weet dat het met sessies werkt als je dat niet weet probeer je het misschien maar een keer.

Maar ik heb nou geen tijd meer, als iemand anders nog wat tijd over heeft zou ik zeggen:
"leef je uit en ga maar verder in dit topic, maar post wel je source "

naast dat kan ik op mijn server php scripts ook in .js bestanden laten runnen dus niemand komt er dan achter dat er serversidescripting achter zit.

[ Voor 10% gewijzigd door Verwijderd op 06-05-2003 16:22 ]

[.oisyn]

Verwijderd schreef op 06 May 2003 @ 14:57:
[...]

Een cms is dus een Content Mangament System de hits hiervan zijn dus != aan de hits op de site zelf.
Want alleen de mensen die de site beheren (een handje vol) zullen toegaan hebben tot de CMS dus hits op percies het zelfde moment (en dan heb ik het dus over micro secondes) zullen verwaarloosbaar zijn.

Daarnaast ook al zou je zo iets gebruiken op een pagina met 1000+ hits per dag de kans dat het dan fout gaat blijft ontzettend klein omdat het over milli secondens gaat.

help me herinneren dat ik mijn site niet door jou laat maken
Sorry een beetje sarcasme, maar ik vind dit persoonlijk een erg slechte manier van software development. Er zit een vrij lange tijd tussen het eind van test.php en het eind van java.php. Als een client een request heeft gedaan wordt test.php uitgevoerd. Dit is een vrij snel proces, en je kunt wel stellen dat java.php direct de goede content heeft. Over het algemeen wordt de output gebuffered, waardoor de gegenereerde html dus pas naar de browser verstuurd wordt nadat java.php is aangepast.

Het moment voor het versturen noemen we t₀

Goed, de data komt mondjesmaat binnen, de browser moet het parsen, en op een gegeven moment stuit hij op een script tag in de html. De browser kan als ie dit ziet gelijk een request doen, of daar even mee wachten. Als ie het gelijk doet moet er eerst weer een verbinding worden opgezet (hoewel dit met keep-alive, wat veelal gebruikt wordt, niet hoeft), en vervolgens wordt de request verstuurd. Je server software interpreteerd je request, opent java.php, en begint met het uitvoeren van het script. Je script output wat javascript sourcecode, waarop ie vervolgens de inhoud van java.php weer ongeldig maakt.

Dit is t₁.

Tussen t₀ en t₁ kan behoorlijk wat tijd zitten, zeker op een wat drukke dag. Of misschien als iemand gewoonweg een trage verbinding of een computer heeft. Je kunt er dus donder op zeggen dat het voorkomt dat er in die periode nog een of meerdere requests binnen komen, waardoor de kans groot is dat een of meerdere van die requests gewoon de mist in lopen omdat java.php op dat moment niet de goede content heeft.

Dit klopt ook niet helemaal he als de request gedaan is,is de javascript source al gecached en wordt er dus nooit een verkeerd bestand gegeven bij het requesten behalve als het wissen in de micro seconde valt tussen het copieren en uitvoeren van java.php. Dus de werking zou zo verlopen waar het vet gedrukte dus door mij is toegevoegd.

uhm, je aanpassingen zijn nogal krom:

- Client 1 doet een request naar test.php
- iets.php wordt gekopieerd naar java.php
- java.php wordt verwijderd en dummy.php komt ervoor in de plaats

waarom? Als een client test.php request, moet java.php toch de goede content krijgen? Dus iets.php, waar de juiste content in staat, wordt op dat moment naar java.php gekopieerd (tenminste, dat is wat je daarnet zei).

Pas als de request naar java.php klaar is wordt de content van java.php weer onjuist gemaakt.

- Client 1 doet een request naar java.php
- java.php wordt verwijderd en dummy.php komt ervoor in de plaats
- iets.php wordt (opnieuw) gekopieerd naar java.php
- java.php wordt verwijderd en dummy.php komt ervoor in de plaats

Met andere woorden, als je een request doet naar java.php krijg je altijd het goede bestand. Tenminste, zo staat dat hier. Als je een request doet wordt iets.php immers over java.php heen gekopieerd. Waar is de beveiliging dan?

[Verwijderd]

.oisyn schreef op 06 May 2003 @ 16:24:
Er zit een vrij lange tijd tussen het eind van test.php en het eind van java.php…
…Goed, de data komt mondjesmaat binnen, de browser moet het parsen, en op een gegeven moment stuit hij op een script tag in de html. De browser kan als ie dit ziet gelijk een request doen, of daar even mee wachten. Als ie het gelijk doet moet er eerst weer een verbinding worden opgezet (hoewel dit met keep-alive, wat veelal gebruikt wordt, niet hoeft), en vervolgens wordt de request verstuurd. Je server software interpreteerd je request, opent java.php, en begint met het uitvoeren van het script. Je script output wat javascript sourcecode, waarop ie vervolgens de inhoud van java.php weer ongeldig maakt….
…Je kunt er dus donder op zeggen dat het voorkomt dat er in die periode nog een of meerdere requests binnen komen, waardoor de kans groot is dat een of meerdere van die requests gewoon de mist in lopen omdat java.php op dat moment niet de goede content heeft.

Het einde van test.php heeft niks meer met java.php te maken.
Hierdoor veranderd de situatie dus; Zoals je kunt zien in de source wordt het originele java.php pas gekopieerd nadat de parent pagina geladen is, het zelfde geldt voor het kopiëren van de dummy.
Maar of dit nou een beter situatie is ? In iedergeval gebeurt het kopieren en wissen nadat de html content geladen is, zolang je de script tags als laatste hebt in de html.


En zoals ik al eerder zei bij een CMS waar maar een paar mensen, soms zelfs een, toegang toe hebben is de kans zeer klein dat zo’n conflict zou plaatsvinden en mocht dat toch gebeuren dan kunnen ze altijd nog op F5 drukken.

Dit vindt ik een acceptable risco net zoals ik als eis heb dat voor online CMS er ie4 of hoger wordt gebruikt. Want een offline CMS heb ik ook ontwikkeld maar er zijn mensen die vaker van huis zijn dan thuis en dezen willen dan wel via elke computer hun content bij werken.

[ Voor 11% gewijzigd door Verwijderd op 06-05-2003 16:53 ]

[Banpei]

Verwijderd schreef op 06 May 2003 @ 16:20:
Dit is volgens mij oplossen door een sessie aan te maken die alleen in het huidige window geldt als dat kan (dacht het wel). Daarnaast druk je een paar keer op F5 omdat je weet dat het met sessies werkt als je dat niet weet probeer je het

Als je de pagina laad en "opslaan als ... " doet in IE dan slaat ie het dus nog wel goed op. Als je dan dus even afwacht tot de KeepAlive van je webserver voorbij is kan je het iig niet meer opslaan. Dus meestal kan je nog zo'n 15 seconden (standaard van Apache) na het laden van de pagina het alsnog direct opslaan.

[Mayco]

gewoon http://www.onssneek.nl/test/java.php downen

edit: eerst wel de session_load.php openen

[ Voor 31% gewijzigd door Mayco op 07-05-2003 13:46 ]

[.oisyn]

Mayco2 schreef op 07 mei 2003 @ 13:41:
gewoon http://www.onssneek.nl/test/java.php downen

wat is je punt? lees de topic! Je hebt zojuist de foutieve versie gedownload (wat idd maar weer bewijst dat lang niet iedereen zo slim is om te concluderen dat de zojuist gedownloade file verkeerd is )

[Mayco]

.oisyn schreef op 07 mei 2003 @ 13:44:
[...]


wat is je punt? lees de topic! Je hebt zojuist de foutieve versie gedownload (wat idd maar weer bewijst dat lang niet iedereen zo slim is om te concluderen dat de zojuist gedownloade file verkeerd is )

je hebt wel gelijk met de volledige topic lezen (had niet gezien dat er 3 pages waren, maar ik had wel de goede file binnen hoor:


//dit is nou mijn javascript protection fase 6

//Pindakaas stinkt

alert("Versie 6:\n Wie oh Wie kan nu nog bij de javascript source komen?");
//goed he
//Nutteloze shit dus, post even hoe je dit gedaan hebt in het topic op:

//[rml]Rutger extreme in "[ php]Een goede manier om een .js te beve"[/rml]

[.oisyn]

.edit: hmm mijn berichtje kwam even niet goed door

overigens, nu staat dit erin:

code:

//dit is nou mijn javascript protection fase 6 :/
//Pindakaas stinkt
alert("Versie 6:\n Wie oh Wie kan nu nog bij de javascript source komen?");
//goed he :'(
//Nutteloze shit dus, post even hoe je dit gedaan hebt in het topic op:
//http://gathering.tweakers.net/forum/list_message/17709338

ik heb met de hand eerst session_load.php geopend, en daarna java.php
Niet zo slim om die sessie-start als javascript in de html te zetten

Mayco2 schreef op 07 May 2003 @ 13:47:
[...]


je hebt wel gelijk met de volledige topic lezen (had niet gezien dat er 3 pages waren, maar ik had wel de goede file binnen hoor:

misschien had je de mazzel dat java.php nog de goede content bevatte

[ Voor 29% gewijzigd door .oisyn op 07-05-2003 14:12 ]

[McVirusS]

Dus we komen wederom tot de conclusie dat het gewoon niet mogelijk is. Ook in W&G zijn al verschillende pogingen gewaagd.

[Mayco]

.oisyn schreef op 07 mei 2003 @ 14:09:
.edit: hmm mijn berichtje kwam even niet goed door

overigens, nu staat dit erin:

code:

//dit is nou mijn javascript protection fase 6 :/
//Pindakaas stinkt
alert("Versie 6:\n Wie oh Wie kan nu nog bij de javascript source komen?");
//goed he :'(
//Nutteloze shit dus, post even hoe je dit gedaan hebt in het topic op:
//http://gathering.tweakers.net/forum/list_message/17709338

ik heb met de hand eerst session_load.php geopend, en daarna java.php
Niet zo slim om die sessie-start als javascript in de html te zetten


[...]


misschien had je de mazzel dat java.php nog de goede content bevatte

nee, gewoon eerst die session_load.php met de hand openen.

[RolandWitvoet]

hey topicstarter, bij mij werkt de pagina niet, maar ik kan wel de source achterhalen
Je bent behoorlijk doorgeschoten met je 'beveiliging. Nog steeds is hij zo waterdicht als een zeef zonder bodem, maar je hebt het inmiddels wel voor elkaar dat het bij sommige gebruikers niet meer werkt.

Wat tips:
- Als je iets niet opgenomen wilt hebben in de browsercache, dan kun je dat aangeven in de header. Meteen een file weer overschrijven is dom. Het is gewoon dom geluk dat het werkt in IE, mozilla en netscape gebruiken een willekeurige naam om een file te cachen en je krijgt dus aparte 2 files.
- een domme (maar volkomen terechte) browser ziet dat hij de file al heeft binnengehaald en zal de tweede file niet downloaden (en slimme browser ziet dat het om een mogelijk dynamisch script gaat ipv een statische pagina (dat mag wel niet, maar ach, wie houdt zich tegenwoordig nog aan de regels?) , dus die zal hem toch weer downloaden) Ook proxys kunnen in deze situatie ongewenst (maar terecht) cachen.
- moderne browsers (IE uitgezonderd) halen meerdere files tegelijk binnen En daarme heb je precies 2 hits tegelijk.
- gebruik https
- maak een encrypted tunnel mbv javascript. als het je lukt: (maar het is nog steeds niet veilig omdat een 'hacker' gewoon aan het einde van die tunnel de data kan opvangen)
- parse alle loopjes en functies al serverside, en stuur alleen de commando's door die achter elkaar moeten worden uitgevoerd. (geen "for a=1 to 10:print (a)" maar "print ('12345678910') dus) Dit werkt echter alleen voor complete scripts die clientside veel moeten doen onafhankelijk van de client (en denk ook aan problemen met variable scopes ) en daarmee zijn het eigenlijk vrij nutteloze scripts omdat je ze zowiezo al serverside had kunenn doen.


En dan nog: vergeet het!
het is gewoon onmogelijk. Alle javascript die uitgevoerd moet worden moet ook naar de client gestuurd worden. En als de browser het kan lezen dan kan ik het ook lezen (denk packetsniffers, maar bijvoorbeeld ook gewoon de javascript debugger van mozilla)

Hoe heb jij toruwens javascript geleerd? nooit gekeken naar andermans code? Als je dat wel hebt gedaan dan is het natuurlijk flauw om jouw code vervolgens te verbergen.

Of (en ik denk dat dat hier het geval is) jij wil wat code gebruiken waarvan de eigenaar vindt dat jij hem daarvoor een vergoeding schuldig bent (aka auteursrechtelijk beschermd) maar jij wil dat gratis doen zonder dat die auteur kan achterhalen dat jij zijn code gejat hebt.

[Verwijderd]

Hmm, wat ik heb gedaan om de source te achterhalen is:

Start IE, vraag dit bestand op session_load.php
Vervolgens vraag je het volgende bestand op in dezelfde browser....

en Voilla je hebt de source... Sessions veranderen namelijk niet in dezelfde browser. Ook niet als je een andere URL intypt.

[.oisyn]

Mayco2 schreef op 07 mei 2003 @ 14:38:
nee, gewoon eerst die session_load.php met de hand openen.

dan heb je dus niet "gewoon" java.php geopend, zoals je zei (ja ok, uiteindelijk wel, maar je hebt een essentieel deel weggelaten )

[ Voor 15% gewijzigd door .oisyn op 07-05-2003 15:44 ]

[Verwijderd]

RolandWitvoet schreef op 07 May 2003 @ 14:56:
Of (en ik denk dat dat hier het geval is) jij wil wat code gebruiken waarvan de eigenaar vindt dat jij hem daarvoor een vergoeding schuldig bent (aka auteursrechtelijk beschermd) maar jij wil dat gratis doen zonder dat die auteur kan achterhalen dat jij zijn code gejat hebt.

Ik een hekel aan suggereren stel het dan in vraag vorm.

[Verwijderd]

sjokki schreef op 06 May 2003 @ 16:04:
Zucht: http://sjokki.ath.cx/kansloos.png
Alles wat binnen komt is te lezen.

heel stom vraagje mischien en mischien wel volledig offtopic: maar hoe heet zo'n pakketje voor winhooz lijkt me wel gemakkelijk..

[Glimi]

Verwijderd schreef op 07 May 2003 @ 19:59:
heel stom vraagje mischien en mischien wel volledig offtopic: maar hoe heet zo'n pakketje voor winhooz lijkt me wel gemakkelijk..

offtopic:
Ethereal

[Verwijderd]

sjokki schreef op 06 May 2003 @ 16:04:
Zucht: http://sjokki.ath.cx/kansloos.png
Alles wat binnen komt is te lezen.

Natuurlijk daar is het client side voor. Je kan het daartegen wel zo moeilijk mogelijk maken Daarom gebruik ik een wat lichter versie dan de laatste, dus zonder al die kopieer zooi

[Verwijderd]

Glimi schreef op 07 mei 2003 @ 20:01:

offtopic:
Ethereal

offtopic:
gezocht en gevonden, maar is der ook iets dat ietsje pietsje kleiner is dan 10 mb

[ Voor 4% gewijzigd door Verwijderd op 07-05-2003 23:14 ]

[crisp]

Verwijderd schreef op 07 May 2003 @ 23:13:
[...]

offtopic:
gezocht en gevonden, maar is der ook iets dat ietsje pietsje kleiner is dan 10 mb

offtopic:
gewoon zoeken op http packet sniffer