[.NET] Safe code

[whoami]

Vandaag las ik dit artikel op MSDN.

Hieruit blijkt dus dat je mbhv reflection private fields/methods van een class kunt invoken:

code:

MyClass o = new MyClass();

Type t = o.GetType();

FieldInfo[] fi = t.GetFields (BindingFlags.NonPublic | BindingFlags.Instance);
// fi bevat nu alle fields die niet public zijn.
MethodInfo[] mi = t.GetMethods (BindingFlags.NonPublic | BindingFlags.Instance);
// mi bevat alle non public methods

// private method invoken:
MethodInfo m = t.GetMethod ("aMethodName", BindingFlags.NonPublic | BindingFlags.Instance);
m.Invoke ( o, .... );
// hetzelfde geldt voor een private field een value te geven.
FieldInfo f = t.GetField ("afield", BindingFlags.NonPublic | BindingFlags.Instance);
f.SetValue ( .... );

In het bovenstaande artikel staat ook hoe je je code veiliger kunt maken (hoe je er voor kunt zorgen dat bovenstaande niet zomaar meer mogelijk is).

Een must read voor iedere .NET developer.

[Verwijderd]

Grappig, dat kan/kon in Java ook. Ik zie eigenlijk niet wat het nut er van is? Waarom maken ze dat mogelijk? Of is het een bug?

[ Voor 59% gewijzigd door Verwijderd op 09-04-2004 19:00 ]

[Feyd-Rautha]

Ik denk niet dat dit een bug is, maar eerder een bijwerking van reflection.

Want alles wat whoami doet in de code is toch volkomen volgens de regels van de kunst en niet een stom toeval.

[vinnux]

Ik kan me wel voorstellen dat je die functionaliteit niet wil. Op deze manier kan een script willekeurig een x classes initieren of oppakken en zomaar wat functies af gaan schieten.
Kan best gevaarlijk zijn, maar ja dit soort zaken probeer je eigenlijk altijd te vermijden toch?

Maar dat je private functies can invoken is wel gevaarlijk, bah bah bah en nog eens bah. FF onderzoeken of het echt zo werkt.

[ Voor 19% gewijzigd door vinnux op 09-04-2004 20:31 ]

[Macros]

Verwijderd schreef op 09 april 2004 @ 18:59:
Grappig, dat kan/kon in Java ook. Ik zie eigenlijk niet wat het nut er van is? Waarom maken ze dat mogelijk? Of is het een bug?

In Java kan je de private fields en methods niet invoken, dan krijg je een exception.

[mbravenboer]

Macros: In Java kan je de private fields en methods niet invoken, dan krijg je een exception.

Het is wel mogelijk (en hier een keer op GoT besproken). In Java zit het wel iets anders in elkaar: je kan at runtime de toegankelijkheid van velden en methoden veranderen. Als je dat niet doet, is het inderdaad niet mogelijk een private methode of veld aan te roepen, ook niet met reflectie. Het aanpassen van de toegankelijkheid is weer alleen mogelijk als er geen security manager draait. De situatie dus niet zo dramatisch.

[whoami]

Het is mogelijk om het niet mogelijk te maken (); althans, je kan ervoor zorgen dat enkel assemblies die een bepaalde sleutel kennen dit kunnen doen.
't Staat in het artikel uitgelegd, het gaat er ook om dat je je apps niet in een 'fully trusted' omgeving moet laten draaien:

The goal of this column was to demonstrate that many of the security features of the CLR can only be enforced in a partial-trust environment.

(Volgens dat artikel zou het ook in C++ mogelijk zijn).

[whoami]

Dit zal waarschijnlijk ook een interessant document zijn voor .NET devvers.
_{'k Moet het zelf nog eens lezen.}

[CaptBiele]

whoami schreef op 20 april 2004 @ 11:37:
Dit zal waarschijnlijk ook een interessant document zijn voor .NET devvers.
_{'k Moet het zelf nog eens lezen.}

Ik heb er even door heen gelezen, en het is geen lichte kost. Ik heb er best moeite mee om het als een beginner te lezen

misschien een beetje offtopic, maar ik had nog een klein vraagje over iets wat ook met veiligheid te maken heeft
zijn parameterized queries hetzelfde als stored procedures? Ik denk het zelf niet omdat de parameterized queries niet als objecten worden opgeslagen op de DBMS, maar ik weet het niet zeker...

[whoami]

In welk opzicht bedoel je 'hetzelfde'?

Qua performance zou het min of meer hetzelfde moeten zijn, het enige verschil zit 'm erin dat je bij een SP enkel de procedure-name over het netwerk moet sturen, terwijl je bij een PQ de volledige query over het netwerk naar de DB moet sturen.

Lees anders dit eens.

[ Voor 15% gewijzigd door whoami op 20-04-2004 14:04 ]

[LoekD]

Wat ook een leuke, goed leesbare bron van kennis is:
http://www.develop.com/kbrown/book/html/book.html

Dat borduurt hier redelijk aardig op voort. (Komt van blogs.msdn.com, ook zo'n ontzettend geweldige bron van MS kennis(en) )

Is er IEMAND hier die zijn/haar (win)apps ontwikkelt onder een niet-admin profiel?
En wie bouwt er nu echt secure code volgens bovenstaande regels?

[CaptBiele]

whoami schreef op 20 april 2004 @ 14:02:
In welk opzicht bedoel je 'hetzelfde'?

Qua performance zou het min of meer hetzelfde moeten zijn, het enige verschil zit 'm erin dat je bij een SP enkel de procedure-name over het netwerk moet sturen, terwijl je bij een PQ de volledige query over het netwerk naar de DB moet sturen.

Lees anders dit eens.

Ik bedoelde inderdaad de performance...

Dat is een interessant artikel. Ik d8 inderdaad (en met mij vele anderen) dat de implementatie van SP`s gewoon een goed gebruik was... blijkbaar niet dus.

Ik heb weinig ervaring met (grote aantallen) SP`s dus ik weet niet of er meer tweakers zijn die vinden dat ze lastig te onderhouden zijn?

Nu nog de comments gaan lezen.....

[whoami]

CaptBiele schreef op 20 april 2004 @ 14:33:
[...]

Ik bedoelde inderdaad de performance...

Dat is een interessant artikel. Ik d8 inderdaad (en met mij vele anderen) dat de implementatie van SP`s gewoon een goed gebruik was... blijkbaar niet dus.

Mjah, je moet natuurlijk ook alles met een korreltje zout nemen.
Stored Procedures zijn niet slecht, parametrized queries ook niet.

Ze zijn beiden te gebruiken; je moet enkel voor jezelf nagaan wanneer je beter een SP gebruikt, en wanneer je beter een PQ gebruikt.
Als het gaat om queries waarvan de where-clausule afhankelijk is van de user-input; ik bedoel als je enkel at runtime gaat weten op welke velden dat de user op wilt filteren, dan moet je zowiezo naar PQ's kijken.

Ik heb weinig ervaring met (grote aantallen) SP`s dus ik weet niet of er meer tweakers zijn die vinden dat ze lastig te onderhouden zijn?

Tja.... de stored procedures worden in het DBMS opgeslagen. Ze staan dus centraal.
Het enige nadeel is dat het DBMS geen version-control bevat voor die SP's, maar dat geldt ook voor triggers, UDF's, etc....
Als je dat wil, kan je natuurlijk iedere SP, trigger, etc.... ook in je version-control opnemen, maar dat brengt dan weer wat extra werk met zich mee.


Maar goed, back ontopic:
Ik ontwikkel idd ook onder een administrator-account en ik denk dat dat idd voor de meeste mensen geldt. Het is nl. het makkelijkste; echter, ik denk dat ik toch eens ga testen om in een meer restricted environment te devven.

[LoekD]

't Begint natuurlijk bij development, maar ook voor installatie en gebruik is het wijsheid om respectievelijk power~ en gewone user accounts te vereisen.
(Vereisen van je programmatuur..niet van de gebruiker natuurlijk)

Zodat evt. fouten van jouw kant of code van kwaadwillenden minimale schade kan aanrichten..

[whoami]

Nog een linkje over partially trusted code:
klik