zoals hierboven te zien is, geeft de code een fout “Exception in thread “main” java.lang.Classcastexceptie: testserialisatie.ExploitDeser kan niet worden gegoten om testserialisatie.Werknemer ” wat betekent dat het type-casting is niet goed, maar de code wordt nog steeds uitgevoerd. De readObject functie van de deserializedemo klasse is in staat om de aangepaste implementatie van de readObject van ExploitDeser klasse uit te voeren.,
Dit is de onveilige deserialisatie hier, dat hoewel er een type-casting fout nog steeds als serialized gegevens van een aangepaste klasse met een aangepaste implementatie van readObject wordt verstrekt als invoer, het wordt uitgevoerd zoals hierboven getoond.
Dit wordt gedaan door de gadgetketens die gebruikt worden door ysoserial en andere java deserialisatie-exploitatietools waar ze zoeken naar chaining van klassen om uiteindelijk te landen in een aangepaste implementatie van readObject die systeemniveau code kan uitvoeren als onderdeel van gebruikersinvoer.,
herstel
nu we hebben gekeken naar wat deserialisatie is en hoe het wordt uitgebuit, laten we kijken naar de sanering hiervan.
de oplossing die we hier gaan bespreken heet “Look-ahead class validation” waar we de lijst van klassen die we willen deserialiseren op de witte lijst kunnen zetten. Bijvoorbeeld. in ons scenario zouden we verwachten dat alleen werknemer klasse object gegevens te krijgen gedeserialiseerd en voor de resterende Het moet niet toestaan deserialisatie.,
dus, in principe wat deze methode doet is, het overschrijft de functie “resolveClass” die deel uitmaakt van “ObjectInputStream”(gebruikt tijdens deserialisatie) klasse en voert een witte lijst uit van de lijst van classess die moet worden gedeserialiseerd.
nu we klaar zijn met de theorie, laten we beginnen met de implementatie.,
laten we een nieuwe klasse “LookAheadObjectInputStream”maken breid het uit naar ObjectInputSteam klasse, zodat we de member function resolveClass kunnen overschrijven:
in de bovenstaande code kijkt de regel:
if (!desc.getName().equals(Employee.class.getName())) {
in principe of serialized content object van Employee class bevat anders geeft het een fout” ongeautoriseerde deserialisatie poging ” en voorkomt het uitvoeren ervan.,
Nu, de laatste gewijzigde code voor “DeserializedDemo” is, zoals hieronder weergegeven:
In de bovenstaande code in acht nemen van de gemarkeerde code in die in plaats van het aanroepen van de ObjectInputStream klasse, LookAheadObjectInputStream klasse wordt steeds genoemd die voorrang op de resolveClass methode tijdens runtime en voer dienovereenkomstig aan.
nu, laten we de kwaadaardige passeren.,ser-bestand gemaakt eerder als input voor deserialisatie en neem de uitgang:
Zoals boven gezien, dit keer de aangepaste implementatie van readObject van de aangepaste klasse “ExploitDeser” niet uitgevoerd tijdens deserialisatie., In plaats daarvan zijn we voorzien van de aangepaste foutmelding “Unauthorized deserialization attempt” die werd ingesteld in de overgeschreven resolveClass functie onder de LookAheadObjectInputStream klasse.
Dit is een heel eenvoudig voorbeeld van het gebruik van de ‘look-ahead class validation’ methode om onveilige deserialisatie te voorkomen. Een uitgebreide implementatie rond dit idee is de “serialKiller” bibliotheek. Link kan hieronder gevonden worden:
daarom kan dit beschouwd worden als een van de oplossingen om onveilige deserialisatie in java te beperken.,
Ik ben nog steeds op zoek naar andere methoden van verzachtingenwaar ik later over zal bloggen.
geef uw waardevolle feedback. Tot dan blijven hacken en leren….
