[php/js]Security issue

[Verwijderd]

Ik ben bezig met de beveiliging van mijn js scripts, en ik wil het zo voor elkaar hebben dat mijn scripts voor de clients vrijwel niet te bemachtigen zijn. Ik vind het niet zo erg als mensen met veel ervaring de code uiteindelijk wel kunnen bekijken omdat ik er dan zo ongeveer wel vanuit kan gaan dat deze client zelf ook wel in staat is om dergelijke js code te schrijven.

Ik wil dus voorkomen dat mensen die zelf geen moeite willen steken in iets uitprogrammeren maar dit gewoon kopieren van bijvoorbeeld een website van mij, zonder moeite mijn code kunnen gebruiken.

Volgens mij is het me best een aardig eindje gelukt ondanks dat ik hier veel lees over lastig of niet te beveiligen js code. Ik kan mijn eigen code in ieder geval zomaar niet opvragen.

Ik heb mijn code nu zo beveiligd dat als je het los opvraagd een leeg js script terug wordt gegeven en als je de pagina opslaat worden de js scripts die geinclude worden niet mee opgeslagen.

Waar ik waarschijnlijk nog rekening mee moet houden, is dat iemand een pagina maakt dat mijn script include en de inhoud als text weergeeft. Maar zolang de pagina die dat doet niet op dezelfde server staat moet dat wel mogelijk zijn volgens mij.

Ik denk dat ik de client dan toch aardig wat mogelijkheden om js scripts te kopieren ontnomen heb.

Hoe denken jullie over dit probleem, en heeft mijn oplossing wel zin?
Bekijk anders deze pagina eens en probeer eens te achterhalen waar de alert vandaan komt. Is dat makkelijk? of zal het werkelijk zin hebben

[MisterData]

Misschien je scripts zelf ook nog 'beveiligen' met eval(unescape(geescapede javascriptcode)) ?

[_fm]

code:

document.getElementsByTagName("head")[0].appendChild(document.createElement("script")).src="classes/js/script.js.php";
var scriptList=null;

// add scripts
function addScripts(){
    scriptList=new ScriptList();
    scriptList.addScript("classes/js/timer.js.php");
    scriptList.lastScript().onload=function(){
        timer.setTimeout("alert('blaat')",1000);
    }
}

// body onload function
function load(){
    scriptList.doOnload();
    scriptsToDelete=new Array(0);
    headItems=document.getElementsByTagName("head")[0].childNodes;
    for(var i=0;headItems[i];i++){
        if(headItems[i].tagName=="SCRIPT")scriptsToDelete.push(headItems[i]);
    }
    while(scriptsToDelete!=0)document.getElementsByTagName("head")[0].removeChild(scriptsToDelete.pop());
}

daar zitie, gewoon het .js.php bestandje opvragen met een ingestelde referer die gelijk is aan de pagina waarin het gebruikt wordt.

[Verwijderd]

MisterData schreef op zondag 20 november 2005 @ 21:53:
Misschien je scripts zelf ook nog 'beveiligen' met eval(unescape(geescapede javascriptcode)) ?

Kan aan mij liggen, maar dit lijkt me aardig tijdrovend en eerlijk gezegd ook vrij nutteloos. Waarom zou ik dat doen?

[Wolfboy]

Verwijderd schreef op zondag 20 november 2005 @ 21:57:
[...]

Kan aan mij liggen, maar dit lijkt me aardig tijdrovend en eerlijk gezegd ook vrij nutteloos. Waarom zou ik dat doen?

Security by obscurity

Daarom

Waarschijnlijk is het voor de meeste n00bs al voldoende om dit te doen:

HTML:

<script src="text/javascript">
/* don't try to steal my code! */
</script>

[Verwijderd]

_fm schreef op zondag 20 november 2005 @ 21:53:
daar zitie, gewoon het .js.php bestandje opvragen met een ingestelde referer die gelijk is aan de pagina waarin het gebruikt wordt.

En zo te zien is dat vrij makkelijk, maar ik krijg het zelf zo niet voor elkaar om die in te stellen. Ik ben wel benieuwd hoe je de referer insteld. En is het mogelijk er nog een extra beveiliging in te bouwen zodat je niet alleen de referer hoeft te wijzigen om bij het script te komen?

Wolfboy schreef op zondag 20 november 2005 @ 22:01:
[...]
Security by obscurity

Daarom

Waarschijnlijk is het voor de meeste n00bs al voldoende om dit te doen:

HTML:

<script src="text/javascript">
/* don't try to steal my code! */
</script>

Daar heb ik ook wel aan zitten denken maar zo makkelijk wil ik het ze niet maken. Ik wil het zo goed beveiligen als mogelijk is, helemaal kan toch niet, dat weet ik. Maar ik ben benieuwd in hoeverre het wel kan

[Verwijderd]

Verwijderd schreef op zondag 20 november 2005 @ 21:57:
Kan aan mij liggen, maar dit lijkt me aardig tijdrovend en eerlijk gezegd ook vrij nutteloos

Dit lijkt me het antwoord op je eigen vraag

[Verwijderd]

Hi
Kan je javascript code eigenlijk wel beveiligen?
De Javascript code moet toch altijd volledig beschikbaar zijn voor de browser, dus uiteindelijk moet die geinclude worden in je HTML documument, en aangezien de source van het html document ook zichtbaar is, kan je altijd wel zien waar de browser de JS code vandaan haalt, het zij van uit de HTML pagina zelf, of vanuit een extern JS file..

Of zie ik dat verkeerd? Want als ik ergens fout zit hoor ik het maar al te graag

MvG
Jan
PS. Ikzelf vind het niet zo erg als er iemand met mijn JS code gaat lopen... Echt professionelen zullen dit niet al te snel doen en degene die dan wel de code pikken zijn meestal gebruikers die een homepage voor zichzelf schrijven... En bovendien kan je het als een compliment beschouwen als iemand je code wil pikken, want dat betekent dat je iets goed geschreven hebt

[Shadowman]

Verwijderd schreef op zondag 20 november 2005 @ 22:11:
Daar heb ik ook wel aan zitten denken maar zo makkelijk wil ik het ze niet maken. Ik wil het zo goed beveiligen als mogelijk is, helemaal kan toch niet, dat weet ik. Maar ik ben benieuwd in hoeverre het wel kan

Als je dan in het bestand javascript.php (met mod_negot*blah* kan het bestand javascript.php aangeroepen worden met javascript) een referer-check doet dan is het nog lastiger om zomaar ff een stukje code te rippen (404-header sturen als men gaat kijken naar dat bestand ).

[Wolfboy]

Het klinkt wel leuk die referer bescherming maar het werkt gewoon niet, wat als iemand nou "save all" doet zodat de webpagina + alle plaatjes en andere rommel in 1x opgeslagen wordt?
Dan heeft die heel referer bescherming (en het trucje dat ik liet zien) geen effect meer.

[Erkens]

Zorg dat je code slecht in elkaar zit, dus moeilijk te begrijpen (korte var names en functions, whitespace eruit) en zorg er tevens voor dat het erg specifieke code is, meer kan je niet doen.
Of het nuttig/handig is wil ik niks over zeggen, ik heb daar zo mijn eigen mening over

[Victor]

Verwijderd schreef op zondag 20 november 2005 @ 22:11:
En zo te zien is dat vrij makkelijk, maar ik krijg het zelf zo niet voor elkaar om die in te stellen. Ik ben wel benieuwd hoe je de referer insteld.

Zo:

code:

C:\>nc 212.187.0.217 80
GET /lindenholt/common/initIndex.js.php HTTP/1.0
Referer: http://212.187.0.217/lindenholt/index.php

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Sun, 20 Nov 2005 22:25:29 GMT
Content-type: application/x-javascript
X-Powered-By: PHP/5.0.4
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Sun, 20 Nov 2005 22:25:29 GMT
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache

//http://212.187.0.217/lindenholt/index.php
document.getElementsByTagName("head")[0].appendChild(document.createElement("script")).src="classes/js/script.js.php";
var scriptList=null;

// add scripts
function addScripts(){
        scriptList=new ScriptList();
        scriptList.addScript("classes/js/timer.js.php");
        scriptList.lastScript().onload=function(){
                timer.setTimeout("alert('blaat')",1000);
        }
}

// body onload function
function load(){
        scriptList.doOnload();
        scriptsToDelete=new Array(0);
        headItems=document.getElementsByTagName("head")[0].childNodes;
        for(var i=0;headItems[i];i++){
                if(headItems[i].tagName=="SCRIPT")scriptsToDelete.push(headItems[i]);
        }
        while(scriptsToDelete!=0)document.getElementsByTagName("head")[0].removeChild(scriptsToDelete.pop());
}

Je maakt met bijvoorbeeld telnet (of in mijn geval netcat) een verbinding met jouw server op poort 80 en je stuurt er zelf de HTTP instructies naar toe. Je geeft op welke pagina je wilt via welk protocol, en wat de referer is, en voila, daar is je javascript

Nu denk ik wel dat dit de meesten wel zal tegenhouden, alleen de echte diehards zullen zo ver gaan dat ze je script op deze manier ontfutselen. Al met al lijkt me dit een goede methode.

[Erkens]

King_Louie schreef op zondag 20 november 2005 @ 23:31:
Je maakt met bijvoorbeeld telnet (of in mijn geval netcat) een verbinding met jouw server op poort 80 en je stuurt er zelf de HTTP instructies naar toe. Je geeft op welke pagina je wilt via welk protocol, en wat de referer is, en voila, daar is je javascript

met wget of zelfs een simpel php scriptje bereik je hetzelfde, en dan hoef je nog minder moeite te doen
Of gewoon die js file uit je cache vissen of die page saven, veel makkelijker

[Kayshin]

Of je zet in je opera transfers bij quick download gewoon de link naar het bestand en opent deze...

[martijn_brinkers]

Je kan evt. ook de javascript encrypted opslaan en bij het laden decrypten en zo dynamisch de ontsleutelde javascript toevoegen. Natuurlijk valt ook dat 'te kraken'. Er is niet echt spraken van kraken aangezien alle informatie (de onsleuteling) aanwezig is. Het maakt het alleen nog wat lastiger om de javascript te bemachtigen.
Gebruik maken van de referrer zou ik afraden aangezien het goed mogelijk is dat men de referrer uit heeft staan (ik heb bijv. in Firefox referrer uitgezet). Ook geven veel personal firewalls de mogelijkheid om de referrer uit te zetten. Men hoeft niet te weten waar ik 'vandaan' kwam ('information leakage').

[TheBorg]

http://www.google.com/sea...nl&btnG=Google+Zoeken&lr=

[Verwijderd]

Verwijderd schreef op zondag 20 november 2005 @ 22:34:
[...]
Dit lijkt me het antwoord op je eigen vraag

Het zoveel mogelijk hiden van mijn code geeft mij wel degelijk een prettig gevoel gezien het aantal uren wat er weleens in een lastig script wil zitten, en waarvoor ik de code dus niet 'zomaar' prijs wil geven.

Wolfboy schreef op zondag 20 november 2005 @ 23:14:
Het klinkt wel leuk die referer bescherming maar het werkt gewoon niet, wat als iemand nou "save all" doet zodat de webpagina + alle plaatjes en andere rommel in 1x opgeslagen wordt?
Dan heeft die heel referer bescherming (en het trucje dat ik liet zien) geen effect meer.

Dat referer niet 100% waterdicht is als je het script direct benaderd weet ik ook, maar save all heeft in principe niks met de referer te maken. Als je op save all klikt worden in ieder geval alle scripts die in de pagina geinclude worden gedownload, als je deze echter on run-time erin en er uit zet, dan zul je ze niet zien bij save as ( tenminste niet in ie, mozilla of opera ). Zoals je misschien bij mijn script gezien hebt, include ik 1 js bestand dat ervoor zorgt dat alle andere scripts in de head worden gezet, na de initialialisatie van de scripts, verwijder ik ze weer in de load functie die in de onload van de body aangeroepen wordt. Als je dan op save as klikt zijn de scripts weer weg en worden ze niet gedownload.

Erkens schreef op zondag 20 november 2005 @ 23:17:
Zorg dat je code slecht in elkaar zit, dus moeilijk te begrijpen (korte var names en functions, whitespace eruit) en zorg er tevens voor dat het erg specifieke code is, meer kan je niet doen.
Of het nuttig/handig is wil ik niks over zeggen, ik heb daar zo mijn eigen mening over

Slechte code ben ik sowieso geen voorstander van, het is wel zo prettig als je gewoon je eigen stijl kan gebruiken en er iets eenvoudigs omheen knutseld waardoor de code lastig te verkrijgen is.

King_Louie schreef op zondag 20 november 2005 @ 23:31:
[...]

Zo:

code:

...

Je maakt met bijvoorbeeld telnet (of in mijn geval netcat) een verbinding met jouw server op poort 80 en je stuurt er zelf de HTTP instructies naar toe. Je geeft op welke pagina je wilt via welk protocol, en wat de referer is, en voila, daar is je javascript

Nu denk ik wel dat dit de meesten wel zal tegenhouden, alleen de echte diehards zullen zo ver gaan dat ze je script op deze manier ontfutselen. Al met al lijkt me dit een goede methode.

Bedankt voor je uitleg, ik ga het zelf niet uitproberen. Maar voor zover ik bij jouw zie zal het voor de standaard webscripters inderdaad niet zomaar even te kopieren zijn, en dat was ook zo ongeveer mijn bedoeling.

Erkens schreef op zondag 20 november 2005 @ 23:43:
[...]

met wget of zelfs een simpel php scriptje bereik je hetzelfde, en dan hoef je nog minder moeite te doen
Of gewoon die js file uit je cache vissen of die page saven, veel makkelijker

Met wget heb ik geen ervaring maar saven of uit de cache vissen is bij mijn oplossing volgens mij niet zomaar mogelijk.

Kayshin schreef op maandag 21 november 2005 @ 00:02:
Of je zet in je opera transfers bij quick download gewoon de link naar het bestand en opent deze...

Misschien dat jij een andere opera hebt als ik. Maar bij mij werkt dat toch echt niet...

[Wolfboy]

Ik denk dat je het beste gewoon kan obfuscaten, als je dat goed doet dan willen mensen je code niet eens meer hebben.

Dus zoiets als dit:

JavaScript:

blaat = 'Hier is een tekstje';
alert(blaat);

Naar dit:

JavaScript:

a=alert,a0='tekstje ',a2='een ',a3='is ',a1='Hier ';a(a1+a3+a2+a0);

[Verwijderd]

Wolfboy schreef op maandag 21 november 2005 @ 01:15:
Ik denk dat je het beste gewoon kan obfuscaten, als je dat goed doet dan willen mensen je code niet eens meer hebben.

Dus zoiets als dit:

JavaScript:

blaat = 'Hier is een tekstje';
alert(blaat);

Naar dit:

JavaScript:

a=alert,a0='tekstje ',a2='een ',a3='is ',a1='Hier ';a(a1+a3+a2+a0);

Ja alleen wil ik het dan zelf ook niet meer zien laat staan bugfixen of uitbreiden.

[TheBorg]

Gewoon zelf telkens het origineel bewerken en de obfuscated versie online zetten. Gewoon ff tooltje voor downloaden.

[Gwaihir]

Referer check moet je niet doen op die manier. Je kunt er hooguit mee voorkomen dat mensen jouw script vanaf jouw server gebruiken in hun eigen pagina's. Je moet bij een referer check nl. ook altijd een lege referer string als geldig doorlaten omdat diverse privacy software (zoals Norton Internet Security) de referer blokkeert.

[Verwijderd]

Birdie schreef op maandag 21 november 2005 @ 01:38:
Referer check moet je niet doen op die manier. Je kunt er hooguit mee voorkomen dat mensen jouw script vanaf jouw server gebruiken in hun eigen pagina's. Je moet bij een referer check nl. ook altijd een lege referer string als geldig doorlaten omdat diverse privacy software (zoals Norton Internet Security) de referer blokkeert.

Dan nog is de referer als je het script direct benaderd niet geset waardoor je er nog steeds op kan checken en zo een belemmering voor de client kan vormen.

Ik snap niet waarom ik geen referer check zou kunnen doen, waar ik op check is of de referer geset is of niet, zoniet dan krijg je niks, zo ja het script. Mocht het echter voorkomen dat de client de referer helemaal niet set, dan wordt het inderdaad lastig.

[Wolfboy]

Birdie heeft wel gelijk ja, er zijn meerdere "firewall" programma's die de referer blokkeren en gewoon niets doorgeven (ZoneAlarm deed dit iig ook altijd)
En die mensen zullen je site dus niet kunnen bezoeken, mja moeten ze de referen maar niet blocken hoor

[Helmet]

Ik snap eigenlijk je punt niet, hoe je het ook wend of keert, de browser moet een keer de javascriptcode uitvoeren, dat betekend dat ie voor je client bekend is en dus ook op de een of andere manier te achterhalen is.

Daarbij, heb je iets revolutionairs uitgevonden gemaakt in javascript? of is het gewoon zo dat je een 13-in-een-dozijn script hebt geschreven en daar zo trots op bent dat iemand anders het niet mag of kan gebruiken?

Javascript beveiligen is een beetje zinloos

[Verwijderd]

Wolfboy schreef op maandag 21 november 2005 @ 01:52:
Birdie heeft wel gelijk ja, er zijn meerdere "firewall" programma's die de referer blokkeren en gewoon niets doorgeven (ZoneAlarm deed dit iig ook altijd)
En die mensen zullen je site dus niet kunnen bezoeken, mja moeten ze de referen maar niet blocken hoor

Hm, daar zal ik dan eens naar kijken.

Helmet schreef op maandag 21 november 2005 @ 01:55:
Ik snap eigenlijk je punt niet, hoe je het ook wend of keert, de browser moet een keer de javascriptcode uitvoeren, dat betekend dat ie voor je client bekend is en dus ook op de een of andere manier te achterhalen is.

Daarbij, heb je iets revolutionairs uitgevonden gemaakt in javascript? of is het gewoon zo dat je een 13-in-een-dozijn script hebt geschreven en daar zo trots op bent dat iemand anders het niet mag of kan gebruiken?

Javascript beveiligen is een beetje zinloos

Als je de topic even doorgelezen had zou je mijn punt moeten snappen, evenals waarom ik mijn code niet zomaar prijs wil geven.

[TheBorg]

Mijn favoriete compressor:
http://hometown.aol.de/_ht_a/memtronic/

Maakt zoiets:

code:

$="function updateT¤(e){x¨x§Lª©X;y¨y§Top©Y;if(t¤!=null){t¤.style.lª=(x+10)+¢px¢;t¤.style.top=(y+10)+¢px¢;}}";for(I=7;I>=0;)$=$.replace(eval("/"+String.fromCharCode(163+I)+"/g"),"documen¡ooltip¡=(£t.al¡¥l)?win¡+£t.body.scroll¡¦dow.event.¡:e.page¡eft".split("¡")[I--]);eval($.replace(/¢/g,"\""));

Veel leesplezier.

[Verwijderd]

TheBorg schreef op maandag 21 november 2005 @ 02:10:
Mijn favoriete compressor:
http://hometown.aol.de/_ht_a/memtronic/

Maakt zoiets:

code:

$="function updateT¤(e){x¨x§Lª©X;y¨y§Top©Y;if(t¤!=null){t¤.style.lª=(x+10)+¢px¢;t¤.style.top=(y+10)+¢px¢;}}";for(I=7;I>=0;)$=$.replace(eval("/"+String.fromCharCode(163+I)+"/g"),"documen¡ooltip¡=(£t.al¡¥l)?win¡+£t.body.scroll¡¦dow.event.¡:e.page¡eft".split("¡")[I--]);eval($.replace(/¢/g,"\""));

Veel leesplezier.

Hehe

Dat ziet er wel leuk uit ja, en het zal best werken, maar ik ben toch tegen dergelijke oplossingen. Kost weer allemaal tijd om na elke update je script te compressen, en ik vind of je ziet de code wel, of je ziet de code niet. En bij mij volstaat als alleen de ervaren scripters( of dieven ), mijn scripts kunnen krijgen, bij de ervaren scripters weet ik dat ze het zelf ook kunnen maken en bij ervaren dieven weet je dat ze hun doel waarschijnlijk toch wel berijken.

[crisp]

obfuscaten is mijn mening als je het echt zo graag wilt.

* crisp zal echter nooit iets jatten; zelf schrijf ik het toch beter

[Verwijderd]

Ik heb toch eens even naar dat obfuscaten/compressen gekeken, en via diverse programma's/sites geprobeerd mijn werkende code te compressen, maar ik krijg het gewoon niet werkend.

Deze ( http://hometown.aol.de/_ht_a/memtronic/ ) bijvoorbeeld lijkt het inderdaad goed te doen, maar toch werken mijn bestanden na het compressen niet meer.

Kan het eraan liggen dat ik met objecten werk? Want opzich is het wel een leuke methode, als het maar werkt.

[TheBorg]

Meestal gaat het fout als je de ; op het eind van een regel bent vergeten.

[Verwijderd]

TheBorg schreef op maandag 21 november 2005 @ 22:41:
Meestal gaat het fout als je de ; op het eind van een regel bent vergeten.

Ja dat zag ik ook al ja, maar ik heb het even op een vrij eenvoudige class geprobeerd waarvan ik toch 100% zeker weet dat ik elke regel( behalve achter } of { ) met een ; heb afgesloten.

[crisp]

Dean's Packer is ook wel een goede, maar daar wordt ook al aangegeven:

All statements, including function declarations, must be correctly terminated with semi-colons.

Ik heb net gekeken of mijn lzw-compressor geschikt was voor dit soort doeleinden, maar de compressie-factor daarvan was hooguit zo'n 50%...

[Verwijderd]

het is me toch gelukt, en gezien de compressie vind ik het toch wel een mooie oplossing om ook de js nog door een compressor te halen. Ik gebruik nu de php referer check( zolang die geset is krijg je de js ), ik verwijder de geinclude js bestanden uit de head en ik haal de js door een compressor.

Al met al vind ik het dan toch een mooie beveiliging geworden en ga ik die maar eens in gebruik nemen.

Bedankt voor de hulp.