Bescherming van je broncode tegen decompilatie

[Janoz]

Thrackan schreef op maandag 20 juli 2009 @ 13:41:
[...]


Waarom leg je de security niet op DB niveau?

Programma vraagt om username en password, probeert daarmee een connectie naar de DB te maken.
DB kent user en password klopt? Niks aan het handje.
DB kent user/pass combinatie niet? Dag dag verbinding!

Bijkomend voordeel is dat je de user/password combinaties zelf in de DB kan beheren.

Nadeel is dat je dan enkel de toegang beveiligd hebt. Welke actie de gebruiker vervolgens in de database uit kan halen is vervolgens gelijk aan wat de clientside applicatie kan, zonder de in de applicatie ingebouwde restricties. Heb je update rechten op de click tabel dan kun je daar keurig een update clicktabel set clicks = clicks + MAX-INT van maken.

[Pathogen]

Janoz schreef op maandag 20 juli 2009 @ 13:46:
[...]

Nadeel is dat je dan enkel de toegang beveiligd hebt. Welke actie de gebruiker vervolgens in de database uit kan halen is vervolgens gelijk aan wat de clientside applicatie kan, zonder de in de applicatie ingebouwde restricties. Heb je update rechten op de click tabel dan kun je daar keurig een update clicktabel set clicks = clicks + MAX-INT van maken.

Ook dat is best in te perken op DB niveau.

Geen idee of het een "goede" oplossing is, maar wij maken hier gebruik van programma/modulerechten in de database, plus nog enkele menu items en windows die alleen bruikbaar zijn als ze aan worden gezet in de tabel met securities, per user.
Het inperken van ongewenste acties ligt wat mij betreft dan weer aan de applicatiekant. Als je gezellig een invoervakje hebt waar je SQL in kan inserten ben je als applicatiedevver niet slim bezig.

Maar goed, ik ben niet al te paranoide op dit gebied aangezien alles hier intern draait. In openbare applicaties zal het een stuk nuttiger zijn om alles dicht te timmeren, hier staan de verbindingsgegevens voor de database gewoon in een .ini file (niet de credentials uiteraard, die worden via Domain en databaseservers geregeld).

[Janoz]

Thrackan schreef op maandag 20 juli 2009 @ 14:04:
[...]


Ook dat is best in te perken op DB niveau.

Geen idee of het een "goede" oplossing is, maar wij maken hier gebruik van programma/modulerechten in de database, plus nog enkele menu items en windows die alleen bruikbaar zijn als ze aan worden gezet in de tabel met securities, per user.

Maar jullie werken waarschijnlijk met trusted clients. Clients waarop de gebruiker geen administrator is en jullie wel. Dat is hier niet het geval.

Het inperken van ongewenste acties ligt wat mij betreft dan weer aan de applicatiekant. Als je gezellig een invoervakje hebt waar je SQL in kan inserten ben je als applicatiedevver niet slim bezig.

Het hele issue hier is dat de applicatie in een untrusted omgeving draait. In de applicatie geimplementeerde beperkingen zijn een wassen neus. Je hoeft helemaal geen invoervakje voor SQL in je applicatie in te bouwen. Je levert middels de applicatie eigenlijk alle gegevens aan de gebruiker om gewoon zelf een applicatie met SQL invoervakje te maken.

[chime]

Thrackan schreef op maandag 20 juli 2009 @ 14:04:
[...]
Het inperken van ongewenste acties ligt wat mij betreft dan weer aan de applicatiekant. Als je gezellig een invoervakje hebt waar je SQL in kan inserten ben je als applicatiedevver niet slim bezig.

Elke beperking aan applicatiekant (client dus) kan omzeild worden.
De server gaat daar altijd nog op moeten controleren.

Beperkingen aan de applicatiekant doe je omwille van de volgende redenen:
- gebruiksgemak
- performantie
Het is namenlijk niet gebruiksvriendelijk/efficiënt om de gebruiker zomaar wat te laten ingeven dat dan door de server gevalideerd moet worden (request - response neemt veel tijd in beslag)

Want iemand met slechte bedoelingen kan zich altijd gaan voordoen als "client"

[ Voor 5% gewijzigd door chime op 20-07-2009 15:44 ]

[Verwijderd]

Hoe dan ook ga ik het beveiligen met een obfuscator en deels mijn programma code herschrijven tot dat het een beetje veilig is...

Welke van de 2 zou ik dan het best kunnen gebruiken?

[RobIII]

Verwijderd schreef op maandag 20 juli 2009 @ 18:12:
Welke van de 2 zou ik dan het best kunnen gebruiken?

Dit is volgens mij al de vierde keer ofzo dat je dat vraagt. Waarom kijk je niet eens naar beiden en neem je zelf een besluit op basis van de voor jou belangrijke eisen en wensen die je hebt
Als je een puntenlijstje met voors- en tegens hebt en die naast mekaar zet moet je volgens mij prima zelf kunnen besluiten welke van de 2 (of 30+) je wil gebruiken. Mochten ze op (min-of-meer) voor jou belangrijke punten allemaal hetzelfde zijn dan kun je alsnog (en veel gerichter) vragen welke van de 2 voor jou het best is als je erbij vermeldt welke van die punten dan voor jou belangrijk zijn en waarom je dan twijfelt tussen de x-aantal kandidaten. Daar kunnen we dan veel meer zinnigs op zeggen.

Zoals je de vraag nu stelt krijg je straks 15 man die "A" roepen en 17 man die "B" roepen zonder verdere onderbouwing. En dat terwijl A misschien wel beter voor je is of de "verborgen" optie "C" die niemand noemt. Allen hebben hun voors en tegens; zonder onderbouwingen en er inhoudelijk op in te gaan krijg je dan gewoon "AJAX!! " "Nee PSV! " "Nee Feyenoord " gejoel terwijl het allemaal om 't even is

[ Voor 67% gewijzigd door RobIII op 20-07-2009 18:24 ]

[Verwijderd]

ok, ok sorry, kga dat onmiddellijk doen!!

Bedankt voor de tip, en bedankt voor alle informatie!!!

[mphilipp]

AtleX schreef op maandag 20 juli 2009 @ 10:31:
[...]
Leg eens uit

Nou...elke keer als er een actie van Brein is, moeten we aanhoren hoe zinloos copyright is en dat we tóch wel krijgen wat we willen. Ik verbaas me er dan ook steeds over dat 'dezelfde' mensen die dit soort reacties plaatsen (even gechargeerd, ik weet natuurlijk dat TS een modelburger is die nooit iets download) naarstig proberen hun eigen materiaal wél te beschermen tegen copyright schendingen. Dus ze proberen te voorkomen dat hun foto's worden gesnatched, of hun code wordt gedecompileerd.

Ik beschuldig niemand, maar ik probeer in dat soort situaties de advocaat van de duivel te spelen door mensen een spiegel voor te houden. Ik vind de argumenten altijd nogal eenzijdig: de kant van de consument op namelijk.

Ik realiseer me dat dit een schaamteloze topic-hijack is, maar misschien negeert iedereen het wel. Just as good. Misschien gaan er toch een paar mensen nadenken. De rest mag gewoon in blissfull ignorance verder leven...

btw: ik download ook, ik doe er alleen niet moeilijk over: ik ben een dief!

[Soultaker]

RobIII schreef op maandag 20 juli 2009 @ 18:15:
Als je een puntenlijstje met voors- en tegens hebt en die naast mekaar zet moet je volgens mij prima zelf kunnen besluiten welke van de 2 (of 30+) je wil gebruiken.

Of je gooit ze er allebei overheen; het zal er niet minder obfuscated door worden, toch?

mphilipp schreef op maandag 20 juli 2009 @ 18:49:
Nou...elke keer als er een actie van Brein is, moeten we aanhoren hoe zinloos copyright is en dat we tóch wel krijgen wat we willen. Ik verbaas me er dan ook steeds over dat 'dezelfde' mensen die dit soort reacties plaatsen [..] naarstig proberen hun eigen materiaal wél te beschermen tegen copyright schendingen.

De ironie is nog groter als je bedenkt dat populaire (proprietary) obfuscators als Dotfuscator ook massaal illegaal gekopieerd worden, terwijl daar nota bene ook gratis versies van zijn. Hetzelfde geldt trouwens voor Microsoft's development tools. Ik ben benieuwd hoeveel halfbakken DRM schemes er wel niet met illegaal verkregen tools ontwikkeld zijn.

[ Voor 47% gewijzigd door Soultaker op 20-07-2009 23:32 ]

[tonyisgaaf]

mphilipp schreef op maandag 20 juli 2009 @ 18:49:
[...]
Ik verbaas me er dan ook steeds over dat 'dezelfde' mensen die dit soort reacties plaatsen (even gechargeerd, ik weet natuurlijk dat TS een modelburger is die nooit iets download) naarstig proberen hun eigen materiaal wél te beschermen tegen copyright schendingen. Dus ze proberen te voorkomen dat hun foto's worden gesnatched, of hun code wordt gedecompileerd.
[...]

't Is maar net wat je wilt lezen hè? Uit de (summiere) informatie die de TS heeft gegeven maak ik op dat het om een security issue gaat, niet om de software zelf. De software geeft toegang tot een stuk informatie en de beveiligingsmethode die de TS voor ogen had (obfuscation van de code) om een "geheime" key voor ieder ander te verbergen heeft weinig te maken met bescherming tegen kopiëren.

*weg*

[ Voor 4% gewijzigd door een moderator op 20-07-2009 23:27 ]

[Zoijar]

tonyisgaaf schreef op maandag 20 juli 2009 @ 21:44:
*weg*

Behalve dat hij gewoon gelijk heeft Ik wilde al eerder een soortgelijk iets posten maar dacht toen "ach, laat ook eigenlijk maar". Ook is vaak de code die het meest beveiligd is het minst de moeite waard...

[ Voor 10% gewijzigd door een moderator op 20-07-2009 23:27 ]

[mphilipp]

tonyisgaaf schreef op maandag 20 juli 2009 @ 21:44:
[...]
't Is maar net wat je wilt lezen hè? Uit de (summiere) informatie die de TS heeft gegeven maak ik op dat het om een security issue gaat, niet om de software zelf.

Oh...dán is het heel erg zinvol... Je weet wel erg veel, hè?
Misschien moet je maar even koekelen op die tamtam rondom de OV chip. Alle twieker wijsneuzen wisten toen ook te vertellen dat open source beter was, speciaal voor security.
*weg*

[ Voor 11% gewijzigd door een moderator op 20-07-2009 23:27 ]

[RobIII]

Zo; en nu is 't welletjes geweest. De volgende die ik zie katten krijgt een mail.

offtopic:
Toen ik vroeger samen met mijn broertje in een stapelbed sliep (those were the days...) en hij lag (nou ja...wij lagen ) te klieren stond ons pa altijd even onder aan de trap alles aan te horen. En dan hoorde je opeens "BAM BAM BAM" pa de trap op stormen, "WENG" de deur open en "*Beng* *Beng*" en RobIII en BenIII zagen allebei sterretjes. Er werd niet gevraagd wie er begonnen was of wie zat te klieren. Waar er 2 ruzie hebben hebben er 2 schuld was de redenatie. En zo doe ik het hier nu ook. Basta

[ Voor 81% gewijzigd door RobIII op 21-07-2009 00:09 ]

[H!GHGuY]

Ik denk dat de TS het veel simpeler iets veiliger kan maken.

Sign je assemblies en gebruik die public key om je pass/user/timestamp te encrypten.
Aan de server kant heb je de private key en kun je mooi user/pass/timestamp decrypten en verifieren.
Is de assembly niet (of fout) gesigned, dan krijg je aan de andere kant ook rommel.
Schrijven ze nieuwe software die die public key gebruikt om user/pass/timestamp te encrypten en alsnog in te loggen, who cares. Ze hebben een valide user/pass/timestamp combinatie dus zijn ze een authorized user.

Je probeert je eigen systeem te beveiligen tegen je eigen users. Focus maar eerst op het beveiligen tegen unauthorized users, daar kom je al een heel eind verder mee.

[Remus]

H!GHGuY schreef op maandag 10 augustus 2009 @ 08:16:
Ik denk dat de TS het veel simpeler iets veiliger kan maken.

Sign je assemblies en gebruik die public key om je pass/user/timestamp te encrypten.
Aan de server kant heb je de private key en kun je mooi user/pass/timestamp decrypten en verifieren.
Is de assembly niet (of fout) gesigned, dan krijg je aan de andere kant ook rommel.
Schrijven ze nieuwe software die die public key gebruikt om user/pass/timestamp te encrypten en alsnog in te loggen, who cares. Ze hebben een valide user/pass/timestamp combinatie dus zijn ze een authorized user.

Je probeert je eigen systeem te beveiligen tegen je eigen users. Focus maar eerst op het beveiligen tegen unauthorized users, daar kom je al een heel eind verder mee.

Allereerst zou ik de assembly signen met mijn private key, anders kan iedere gebruiker die mijn public key heeft als nog een valide signature maken.
Maar zelfs met zo'n signatue: pas het programma aan zodat de oorspronkelijke informatie terug gestuurd wordt, tada, beveiliging ook doorgeprikt. Die beveiliging is dus net zo lek. De enige manier om je code te beschermen is door het niet aan de gebruiker ter beschikking te stellen. Maar als webapplicatie/saas oid.

[H!GHGuY]

Remus schreef op maandag 10 augustus 2009 @ 10:09:
[...]

Allereerst zou ik de assembly signen met mijn private key, anders kan iedere gebruiker die mijn public key heeft als nog een valide signature maken.
Maar zelfs met zo'n signatue: pas het programma aan zodat de oorspronkelijke informatie terug gestuurd wordt, tada, beveiliging ook doorgeprikt. Die beveiliging is dus net zo lek. De enige manier om je code te beschermen is door het niet aan de gebruiker ter beschikking te stellen. Maar als webapplicatie/saas oid.

Eerst en vooral, bij signing komt de public key in de assembly te staan, die gebruik je uiteindelijk.
Daarnaast: niet waar. de server verwacht public_key(user, pass, timestamp) en kan met de private key de boel terug decrypten en paswoord verifieren. Elke programmeur kan idd een tool maken die datzelfde berekent.
Bottom-line is dat je nog steeds een geldige user/pass combo nodig hebt om in te loggen.

Beter een goed opgebouwde transparante beveiliging dan een slechte obfuscated beveiliging.

[ Voor 4% gewijzigd door H!GHGuY op 10-08-2009 10:21 ]

[VisionMaster]

H!GHGuY schreef op maandag 10 augustus 2009 @ 10:20:
[...]


Eerst en vooral, bij signing komt de public key in de assembly te staan, die gebruik je uiteindelijk.
Daarnaast: niet waar. de server verwacht public_key(user, pass, timestamp) en kan met de private key de boel terug decrypten en paswoord verifieren. Elke programmeur kan idd een tool maken die datzelfde berekent.
Bottom-line is dat je nog steeds een geldige user/pass combo nodig hebt om in te loggen.

Beter een goed opgebouwde transparante beveiliging dan een slechte obfuscated beveiliging.

Je methode zal niet werken. Als ik de applicatie heb en kan decompilen wat je signing methode is, en de public key heb ik gekregen in de applicatie, dan maak ik mijn eigen private key, wijzig ik wat dingen in de applicatie en sign ik het met mijn eigen key die ik dan weer even goed embed in de applicatie.

Of nog mooier, ik haal de routines uit de applicatie die de signature controleren en in mijn nieuwe versie van de applicatie heeft de signature controle routine altijd een positief en prettig antwoord terug gegeven.

Ergo: "That's cute, but it's wrong"

[H!GHGuY]

VisionMaster schreef op maandag 10 augustus 2009 @ 14:07:
[...]

Je methode zal niet werken. Als ik de applicatie heb en kan decompilen wat je signing methode is, en de public key heb ik gekregen in de applicatie, dan maak ik mijn eigen private key, wijzig ik wat dingen in de applicatie en sign ik het met mijn eigen key die ik dan weer even goed embed in de applicatie.

Of nog mooier, ik haal de routines uit de applicatie die de signature controleren en in mijn nieuwe versie van de applicatie heeft de signature controle routine altijd een positief en prettig antwoord terug gegeven.

Ergo: "That's cute, but it's wrong"

Bedankt om aan te geven dat je het niet snapt.
Ergo:


De private key wordt server-side gehouden en ook daar wordt gecontroleerd of de login valid is.
Veel success met het signen van de recompiled app met je eigen key

[ Voor 9% gewijzigd door H!GHGuY op 10-08-2009 14:31 ]

[Gerco]

H!GHGuY schreef op maandag 10 augustus 2009 @ 14:29:
De private key wordt server-side gehouden en ook daar wordt gecontroleerd of de login valid is.
Veel success met het signen van de recompiled app met je eigen key

Je kan dan als aanvaller natuurlijk altijd de app signen met je eigen key, maar de login doen met de originele public key. Als je de app kan aanpassen kun je dat natuurlijk ook gewoon doen Je kunt alleen niet verbergen dat je het gedaan hebt omdat je de binary niet kunt re-signen met originele key.

[H!GHGuY]

Gerco schreef op maandag 10 augustus 2009 @ 14:40:
[...]

Je kan dan als aanvaller natuurlijk altijd de app signen met je eigen key, maar de login doen met de originele public key. Als je de app kan aanpassen kun je dat natuurlijk ook gewoon doen Je kunt alleen niet verbergen dat je het gedaan hebt omdat je de binary niet kunt re-signen met originele key.

Sure, maar aangezien je een geldige user/pass combinatie hebt, ben je een klant/gekende user.
Anders kom je alsnog niet binnen op de server. Dat is nu mijn hele punt. Maak een transparante maar veilige inlogprocedure en steek dan ook alle belangrijke operaties op de server.

Het enige wat je bereikt is dat je mensen verbiedt om hun eigen software te maken of jouw software aan te passen naar hun noden. Is dat het dan echt waard?

[Remus]

H!GHGuY schreef op maandag 10 augustus 2009 @ 14:29:
[...]

Bedankt om aan te geven dat je het niet snapt.
Ergo:
[afbeelding]

De private key wordt server-side gehouden en ook daar wordt gecontroleerd of de login valid is.
Veel success met het signen van de recompiled app met je eigen key

Dus, probleem bestaat nog steeds: als ik als kraker de public key heb, en die heb ik uit jouw originele programma, dan kan ik nog steeds alles naar hartelust signen met dezelfde informatie zoals in het oorspronkelijke protocol van het onaangepast programma, ook al heb ik de rest van het programma volledig verneukt.

[H!GHGuY]

Remus schreef op maandag 10 augustus 2009 @ 20:15:
Dus, probleem bestaat nog steeds: als ik als kraker de public key heb, en die heb ik uit jouw originele programma, dan kan ik nog steeds alles naar hartelust signen met dezelfde informatie zoals in het oorspronkelijke protocol van het onaangepast programma, ook al heb ik de rest van het programma volledig verneukt.

H!GHGuY schreef op maandag 10 augustus 2009 @ 16:00:
Het enige wat je bereikt is dat je mensen verbiedt om hun eigen software te maken of jouw software aan te passen naar hun noden. Is dat het dan echt waard?

Eindelijk. De euro is gevallen.

Dat is nu wat ik al de hele tijd vertel. Who cares dat iemand een andere client schrijft of jouw client aanpast.
Zolang je je logic op de server implementeert en een goeie interface exposed op de server inclusief beveiliging
is er niets aan het handje. Clients hebben hoe dan ook een geldige user/pass nodig om ingelogd te raken. Gebruiken ze nu client X of Y en is die client buggy of niet, who cares zolang jij de server maar controleert met een goeie interface die je kan beveiligen.

[Remus]

H!GHGuY schreef op dinsdag 11 augustus 2009 @ 08:08:
[...]


[...]


Eindelijk. De euro is gevallen.

Dat is nu wat ik al de hele tijd vertel. Who cares dat iemand een andere client schrijft of jouw client aanpast.
Zolang je je logic op de server implementeert en een goeie interface exposed op de server inclusief beveiliging
is er niets aan het handje. Clients hebben hoe dan ook een geldige user/pass nodig om ingelogd te raken. Gebruiken ze nu client X of Y en is die client buggy of niet, who cares zolang jij de server maar controleert met een goeie interface die je kan beveiligen.

De TS is bang dat mensen zijn programmatuur 'stelen' of aanpassen, maar is tegelijkertijd onwillig om de business logica op de server te gaan doen. Zolang de business logic in de client plaatsvind, zal jouw oplossing dan niet zoveel helpen.

Maar ik moet toegeven, ik heb je posts van gisteren misschien verkeerd gelezen, en hebben we het eigenlijk over hetzelfde.

[H!GHGuY]

Dan kunnen we denk ik gezamenlijk concluderen dat de TS zijn architectuur fout is en dat hij die beter eerst fixt.
In tussentijd kan hij misschien wel een release doen met een obfuscator als .NET reactor (meeste disassembly tools zien niet eens een CLR header), maar op de lange baan fixt hij beter zijn architectuur.