Sök…


Introduktion

Säkerhetspraxis i Java kan delas upp i två breda, vagt definierade kategorier; Java-plattformsäkerhet och säker Java-programmering.

Java-plattforms säkerhetspraxis handlar om att hantera säkerheten och integriteten för JVM. Det innehåller sådana ämnen som hantering av JCE-leverantörer och säkerhetspolicyer.

Säkra Java-programmeringsmetoder gäller de bästa sätten att skriva säkra Java-program. Det innehåller sådana ämnen som att använda slumpmässiga nummer och kryptografi och förebygga sårbarheter.

Anmärkningar

Exempel bör tydligt göras, men vissa ämnen som måste behandlas är:

  1. JCE-leverantörens koncept / struktur
  2. Listobjekt

JCE

Java Cryptography Extension (JCE) är ett ramverk inbyggt i JVM så att utvecklare enkelt och säkert kan använda kryptografi i sina program. Det gör detta genom att tillhandahålla ett enkelt, portabelt gränssnitt till programmerare, samtidigt som man använder ett system med JCE-leverantörer för att säkert implementera de underliggande kryptografiska operationerna.

Nycklar och nyckelhantering

Medan JCE säkrar kryptografiska operationer och nyckelgenerering, är det upp till utvecklaren att faktiskt hantera sina nycklar. Mer information måste tillhandahållas här.

En vanligt accepterad bästa praxis för att hantera nycklar vid körning är att lagra dem bara som byte matriser och aldrig som strängar. Detta beror på att Java-strängar är oföränderliga och inte kan "rensas manuellt" eller "nollas ut" i minnet; medan en referens till en sträng kan tas bort, kommer den exakta strängen att förbli i minnet tills dess minnessegment samlas in och återanvänds. En angripare skulle ha ett stort fönster där de kunde dumpa programminnet och lätt hitta nyckeln. I motsats härtill är byte matriser muterbara och kan ha sitt innehåll överskrivna på plats; Det är en bra idé att "nollställa" dina nycklar så fort du inte längre behöver dem.

Vanliga Java-sårbarheter

Behöver innehåll

Nätverk bekymmer

Behöver innehåll

Slumpmässighet och dig

Behöver innehåll

För de flesta applikationer är klassen java.utils.Random en helt fin källa till "slumpmässiga" data. Om du behöver välja ett slumpmässigt element från en matris, eller generera en slumpmässig sträng eller skapa en tillfällig "unik" identifierare, bör du förmodligen använda Random .

Men många kryptografiska system förlitar sig på slumpmässighet för deras säkerhet, och slumpmässigheten som tillhandahålls av Random helt enkelt inte av tillräckligt hög kvalitet. För alla kryptografiska operationer som kräver slumpmässig inmatning, bör du använda SecureRandom istället.

Hashing och validering

Mer information behövs.

En kryptografisk hashfunktion är medlem i en klass av funktioner med tre vitala egenskaper; konsistens, unikhet och irreversibilitet.

Konsekvens: Med samma data kommer en hashfunktion alltid att returnera samma värde. Det vill säga om X = Y kommer f (x) alltid att vara lika med f (y) för hashfunktion f.

Unikhet: Inga två ingångar till en hash-funktion kommer någonsin att resultera i samma utgång. Det vill säga om X! = Y, f (x)! = F (y), för alla värden på X och Y.

Irreversibilitet: Det är opraktiskt svårt, om inte omöjligt, att "vända" en hashfunktion. Det vill säga, med tanke på endast f (X), bör det inte finnas något sätt att hitta det ursprungliga X för att sätta alla möjliga värden på X genom funktionen f (brute-force). Det bör inte finnas någon funktion f1 så att f1 (f (X)) = X.

Många funktioner saknar åtminstone ett av dessa attribut. Till exempel är MD5 och SHA1 kända för att ha kollisioner, dvs två ingångar som har samma utgång, så att de saknar unikhet. Vissa funktioner som för närvarande tros vara säkra är SHA-256 och SHA-512.



Modified text is an extract of the original Stack Overflow Documentation
Licensierat under CC BY-SA 3.0
Inte anslutet till Stack Overflow