DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Goed, we gaan wegstrepen; wat voor type query is het?quote:
- UPDATE
- DELETE
- SELECT
- INSERT
- Geen van bovenstaande
Dit is wat ik ook doe, met als bijkomstige dienst dat ik ook verzegelde servers verhuurde maar dat laatste liep niet zo heel goed, dus dat heb ik maar stopgezet.quote:Op woensdag 23 mei 2007 23:49 schreef Tuvai.net het volgende:
Of een applicatie maken die op JOUW server draait waar mensen inloggen. Dat is de strategie van het bedrijf waar ik nu voor werk. Die hebben in feite zelf de servers en de software, altijd binnen handbereik, en alle klanten kunnen er gebruik van maken zonder dat iemand de broncode in z'n handen krijgt.
maar dat laatste liep niet zo heel goed, dus dat heb ik maar stopgezet.
Ja, ik werk nu inmiddels twee maanden bij het bedrijf en ik denk er vaak aan waarom ik niet eerder aan zoiets voor mezelf gedacht had. Je hebt niet alleen geen risico dat iemand je broncode verspreidt omdat toch niemand anders dan jij zelf er aan kunt komen (of okee, je zult al met professionele hackers te maken moeten hebben maar die houden zich naar mijn weten met belangrijkere dingen bezig), maar ook alles is meteen toegankelijk voor je als programmeur. Het is heerlijk wanneer d'r bijvoorbeeld een bug of een fout gemeld word, en ik die meteen lokaal 'effe' kan fixen zonder FTP geneuzel.
Daar is weer serverside een compare voor nodig die je er simpelweg uit kan slopen als je een beetje scripting kennis hebt. Ik zat zelf ook die kant op te denken. Vanaf mijn eigen domein elke dag een license file pushen met daarin een hash alogaritme. Je kan dan voor elke installatie een andere hash verzinnen.... Maar wederom het probleem, je moet serverside die hash gaan vergelijken.quote:Op woensdag 23 mei 2007 23:49 schreef Tuvai.net het volgende:
Swets: Elk klant een soort van ID Key / Productcode meegeven en bij installatie door een soot van white list gaan die checkt of het wel een legale versie is die geïnstalleerd word?
Ja elke variant waarbij je controlle over de server hebt is perfect, maar.... not an option. Het is ook meer hypothetisch he. Ik neem ook aan dat ik niet de enige ben met dit 'probleem' en IEMAND zal toch wel eens een werkbare waterdichte oplossing bedacht hebben?quote:Of een applicatie maken die op JOUW server draait waar mensen inloggen. Dat is de strategie van het bedrijf waar ik nu voor werk. Die hebben in feite zelf de servers en de software, altijd binnen handbereik, en alle klanten kunnen er gebruik van maken zonder dat iemand de broncode in z'n handen krijgt.
Ehm, nee. De enige 'veiligheid' die tot nu toe geldt heet 'closed source' en dat noemen ze ook wel 'security through obscurity' dat ze voor spelletjes vage shit hebben bedacht als geforceerde foutjes op de CD of DVD en voor applicaties een licentieactivatie met hardwarekoppeling en 5MB aan omzeilende code wil niet zeggen dat het veilig is, en/of dat je het voor je PHP app kunt gebruikenquote:Op donderdag 24 mei 2007 08:17 schreef Swetsenegger het volgende:
[..]
Ik neem ook aan dat ik niet de enige ben met dit 'probleem' en IEMAND zal toch wel eens een werkbare waterdichte oplossing bedacht hebben?
Dé veiligste manier is alsnog de hele boel intern draaien. Vrijwel elke manier om het te beveiligen in PHP is net zo veilig als de closed source oplossing, minus dat het open source is. Zolang je alle functionaliteit echter bij jouw kant neerlegt, heb je er ook volledige controle over.
Goed ik hoor de klok en heb geen idee waar de klepel precies is maar is ioncube encoder iets om naar te kijken? http://www.ioncube.com/sa_encoder.php
phluphy for president!
Het is goed om even te zien hoe PHP nu eigenlijk werkt. Als je een PHP bestand uitvoert gaat het door de volgende stappen:quote:Op donderdag 24 mei 2007 08:49 schreef WyriHaximus het volgende:
Goed ik hoor de klok en heb geen idee waar de klepel precies is maar is ioncube encoder iets om naar te kijken? http://www.ioncube.com/sa_encoder.php
1) De PHP parser leest je script, controleert het op syntaxfouten e.d.
2) De PHP parser zet vervolgens je script om naar PHP opcodes (compileren, dit is net zoiets als een Java .class)
3) Vervolgens voert de PHP "virtual machine" de opcodes uit
Als je je bestanden codeert met zo'n encrypter, dan voert ie vantevoren stap 1 en 2 al uit. Eventueel combineert ie dit met licenties en encryption. In dat geval worden er deze stappen uitgevoerd:
1) De Encrypter leest je bestand in en controleert evt. licenties e.d.
2) De Encrypter decodeert je bestand naar PHP opcodes
3) Vervolgens voert de PHP "virtual machine" de opcodes uit
De oplettenden zullen al hebben gezien dat je in beide gevallen voor stap 3 dezelfde opcodes moet hebben voor hetzelfde script nu is het punt dat die opcodes echt niet heel moeilijk zijn, en dat als iemand wil hij je scripts kan decoderen en strippen van de 'veiligheidsfeatures'. En dat is onveilig aan alle (voor zover ik gezien heb) PHP encrypters.
Mjah, dus veel verder dan ergens ver weg gestopt een hashcode vergelijken, en die file misschien obfuscaten kom ik niet.quote:Op donderdag 24 mei 2007 08:22 schreef JeRa het volgende:
[..]
Ehm, nee. De enige 'veiligheid' die tot nu toe geldt heet 'closed source' en dat noemen ze ook wel 'security through obscurity' dat ze voor spelletjes vage shit hebben bedacht als geforceerde foutjes op de CD of DVD en voor applicaties een licentieactivatie met hardwarekoppeling en 5MB aan omzeilende code wil niet zeggen dat het veilig is, en/of dat je het voor je PHP app kunt gebruiken
Dé veiligste manier is alsnog de hele boel intern draaien. Vrijwel elke manier om het te beveiligen in PHP is net zo veilig als de closed source oplossing, minus dat het open source is. Zolang je alle functionaliteit echter bij jouw kant neerlegt, heb je er ook volledige controle over.
Ik zat nog te denken aan remote activatie waarbij je per klant een ander essentiëel deel van de applicatie laat downloaden (zo essentiëel dat alleen de activatie nog werkt). Piracy zul je niet echt kunnen voorkomen, maar door slim watermarks (whitespace? eventueel in de output) achter te laten kun je er eventueel wel achterkomen wie het is geweest.quote:Op donderdag 24 mei 2007 09:00 schreef Swetsenegger het volgende:
[..]
Mjah, dus veel verder dan ergens ver weg gestopt een hashcode vergelijken, en die file misschien obfuscaten kom ik niet.
Ook nog een ideequote:Op donderdag 24 mei 2007 09:02 schreef JeRa het volgende:
[..]
Ik zat nog te denken aan remote activatie waarbij je per klant een ander essentiëel deel van de applicatie laat downloaden (zo essentiëel dat alleen de activatie nog werkt). Piracy zul je niet echt kunnen voorkomen, maar door slim watermarks (whitespace? eventueel in de output) achter te laten kun je er eventueel wel achterkomen wie het is geweest.
Goed, niet dat ik verwacht dat iemand mijn apps wil jatten
Als dat niet het geval is hoef je je nergens druk om te maken schrijf eventueel zelf een encrypter, pas de methode die ik hierboven beschreef toe of doe iets anders met remote activatie, dan heb je met niet al te veel moeite een systeem dat de meeste mensen niet kunnen omzeilen. Eventueel kun je nog passieve controle doen (wel eerst toestemming vragen via de applicatie! als ze 'm niet accepteren, dan werkt de app niet) zodat de app eens in de zoveel tijd een signaal naar jou stuurt met productgegevens waardoor jij kunt controleren of ze de app wel eerlijk gebruiken.quote:Op donderdag 24 mei 2007 09:04 schreef Swetsenegger het volgende:
[..]
Goed, niet dat ik verwacht dat iemand mijn apps wil jatten
Mooie en goeie uitleg .quote:Op donderdag 24 mei 2007 09:00 schreef JeRa het volgende:
[..]
Het is goed om even te zien hoe PHP nu eigenlijk werkt. Als je een PHP bestand uitvoert gaat het door de volgende stappen:
1) De PHP parser leest je script, controleert het op syntaxfouten e.d.
2) De PHP parser zet vervolgens je script om naar PHP opcodes (compileren, dit is net zoiets als een Java .class)
3) Vervolgens voert de PHP "virtual machine" de opcodes uit
Als je je bestanden codeert met zo'n encrypter, dan voert ie vantevoren stap 1 en 2 al uit. Eventueel combineert ie dit met licenties en encryption. In dat geval worden er deze stappen uitgevoerd:
1) De Encrypter leest je bestand in en controleert evt. licenties e.d.
2) De Encrypter decodeert je bestand naar PHP opcodes
3) Vervolgens voert de PHP "virtual machine" de opcodes uit
De oplettenden zullen al hebben gezien dat je in beide gevallen voor stap 3 dezelfde opcodes moet hebben voor hetzelfde script nu is het punt dat die opcodes echt niet heel moeilijk zijn, en dat als iemand wil hij je scripts kan decoderen en strippen van de 'veiligheidsfeatures'. En dat is onveilig aan alle (voor zover ik gezien heb) PHP encrypters.
Mooie en goeie uitleg 
.Dat 1 2 3 gebeuren weet ik idd. Maar dan moet je lijkt mij toch al best wat kennis van zaken hebben wil je zo ver komen . Begreep uit het verhaal dat hij zich niet zo heel veel zorgen er over maakt en dit werpt dan toch een extra barrière op . Als ze echt je source willen hebben lukt ze dat toch wel, zolang er iets op een bak van hun staat en kunnen ze gewoon bij de files dan kunnen ze er mee doen wat ze willen en zover ik weet kan je nog steeds binaries decompilen en de ASM er van lezen. (Veiligheid in het algemeen dan.)
phluphy for president!
Zeer interesante link over OPcodes van PHP: http://blog.php-security.(...)n-where-are-you.html
phluphy for president!
Toch inderdaad wel jammer dat PHP het beschermen van broncode zo vermoeilijkt. Dat vind ik aan ASP.NET weer hartstikke handig, dat je een .DLL`etje hebt waar alleen je programma verder iets mee kan. Wellicht krijgt PHP ook nog iets dergelijks in de toekomst?
Hoop het wel .. snuffelenquote:Op donderdag 24 mei 2007 09:58 schreef Tuvai.net het volgende:
Toch inderdaad wel jammer dat PHP het beschermen van broncode zo vermoeilijkt. Dat vind ik aan ASP.NET weer hartstikke handig, dat je een .DLL`etje hebt waar alleen je programma verder iets mee kan. Wellicht krijgt PHP ook nog iets dergelijks in de toekomst?
* WyriHaximus gaat info over PHP6 zoeken
phluphy for president!
Van: http://www.phphacks.com/content/view/49/33/quote:Op donderdag 24 mei 2007 10:11 schreef WyriHaximus het volgende:
[..]
Hoop het wel .. snuffelen
* WyriHaximus gaat info over PHP6 zoeken
quote:* The register_globals, safe_mode and various quotes options will be removed.
* The ereg extension is removed, while the XMLReader, XMLWriter and Fileinfo extensions are added to the core, and by default are on.
* Another addition I find particularly exciting is that APC (Alternative PHP Cache) will be added to the core, though will be off by default. APC can provide serious performance benefits.
* All E_STRICT messages will be merged into E_ALL, another positive change that will encourage good programming practice.
* ASP style <% tags will no longer be supported.
* Addition of new 64-bit integers. The current integer type remains as is, 32 or 64-bit dependent on the platform.
* Use of foreach with multi-dimensional arrays, for example foreach($array as $k => list($a, $b)).
* A new switch in php.ini will allow you to disable Unicode semantics (by default they will be on).
* There will also be various string improvements related to Unicode.
* The microtime() function will return the full floating point number, rather than microseconds unix_timestamp, as at present, probably making the function more readily useful.
* The {} notation for string indexes will no longer be supported, while the [] version will get added to substr() and array_slice() functionality.
* FastCGI will always be enabled for the CGI SAPI, and will not allow it to be disabled.
* The ancient HTTP_*_VARS globals will no longer be supported.
* var will alias public. var was permitted with PHP4 classes, but in PHP 5 this raised a warning. In PHP 6 var will simply be an alias for public, so no warning is necessary.
* The ze1 compatibility mode, which tried to retain PHP 4 behavior but had some bugs, will be removed.
* Dynamic functions will no longer be permitted, to be called with static syntax.
phluphy for president!
Nog meer info hier maar niks over OPcode beveiliging: http://www.php.net/~derick/meeting-notes.htmlquote:Op donderdag 24 mei 2007 10:17 schreef WyriHaximus het volgende:
[..]
Van: http://www.phphacks.com/content/view/49/33/
[..]
phluphy for president!
Ook al op diverse sites naar PHP6 liggen snuffelen, maar inderdaad nog niks op de planning gevonden van het compileren/beveiligen van broncode.
Wil dat zeggen dat je per sé <?php ?> moet gaan gebruiken in plaats van <? ?>? Da's een niet zo prettige verandering voor mij, ben inmiddels al jaren gewend om <? ?> te gebruiken.quote:* ASP style <% tags will no longer be supported.
Nee je kunt <% en %> niet meer gebruiken ipv <?php en ?> en <? en ?> .quote:Op donderdag 24 mei 2007 10:26 schreef Tuvai.net het volgende:
[..]
Wil dat zeggen dat je per sé <?php ?> moet gaan gebruiken in plaats van <? ?>? Da's een niet zo prettige verandering voor mij, ben inmiddels al jaren gewend om <? ?> te gebruiken.
.
phluphy for president!
ik dnek niet dat ze shorttags eruit gaan slopen omdat zo'n beetje iedereen die gebruikt. Vooral in de <?=$variable;?> variant is dat rete makkelijk.
Maar toch... ook NU kan je plotseling geconfronteerd worden met een niet werkende app omdat in de php.ini shorttags uit staat
Maar toch... ook NU kan je plotseling geconfronteerd worden met een niet werkende app omdat in de php.ini shorttags uit staat
Of je vernaggeld heel je code qua variabele namen middels een "Replace all" in je teksteditor.
:Y)
| 1 2 3 4 5 6 7 | foreach ($wii as $waa){ echo $waa['wuu']; } ?> |
:Y)
CTRL Zquote:Op donderdag 24 mei 2007 10:41 schreef Geqxon het volgende:
Of je vernaggeld heel je code qua variabele namen middels een "Replace all" in je teksteditor.
[ code verwijderd ]
quote:Op donderdag 24 mei 2007 10:41 schreef Geqxon het volgende:
Of je vernaggeld heel je code qua variabele namen middels een "Replace all" in je teksteditor.
[ code verwijderd ]
:Y)
| 1 2 3 4 5 6 7 | foreach ($waa as $waa){ echo "wie".$waa; } ?> |
