Håll dig före Java – säkerhetsproblem som SQL-och LDAP-injektioner

Om du, som om 10 miljoner andra människor, är en Java-utvecklare, vill du förmodligen veta hur du håller Java-koden säker. Utvecklare kommer alltid att behöva hålla koll på tips och bästa praxis för att hantera Java-säkerhetsproblem.

Java är det mest populära programmeringsspråket idag, med goda skäl. Java-kod är plattformsoberoende. Java-programmering lärs allmänt i universitetets datavetenskapliga avdelningar. Så många ivriga programmerare går in i sina första jobb redo att koda i Java. Och Java: s objektorienterade design gör det enkelt att återanvända kod.

ändå, trots Java popularitet, skulle du vara hårt pressad för att hitta någon som skulle argumentera Java är det säkraste programmeringsspråket där ute. Java säkerhetsproblem är verkliga. Java var utformad för att vara lika säker som de flesta andra populära programmeringsspråk, och det erbjuder funktioner som SecurityManager för att förbättra säkerheten i vissa sammanhang. Java-applikationer är dock föremål för ett antal potentiella säkerhetsproblem, inklusive men inte begränsat till olika injektionsattacker.

det är viktigt för Java-utvecklare och administratörer att ha gemensamma Java-säkerhetsproblem i åtanke när de skriver och distribuerar Java-applikationer. Säkerhet – första programmering är särskilt viktigt när det gäller Java eftersom Java-kodens plattformsoberoende karaktär innebär att säkerhetsramar på OS-nivå inte alltid kan lita på att hålla applikationer säkra.

Du bör inte heller förvänta dig att slutanvändare ska kunna hantera Java – säkerhetshot effektivt. Visst kan du skylla dina användare för att köra otillförlitlig Java-kod eller inaktivera automatiska uppdateringar av deras Java-körtider, men i slutändan ligger bördan att skriva säkra Java-applikationer och isolera kod i en Java-miljö som kanske inte är säker hos utvecklare.

vanliga Java-säkerhetsproblem

Java-programmerare bör ha följande säkerhetsutmaningar i åtanke när de utformar och skriver Java-applikationer.

SQL-injektioner

SQL-injektioner uppstår när en angripare infogar skadlig SQL-frågekod i ett formulär. Om applikationen inte upptäcker den skadliga koden och skickar den till en databas kan databasen ändras på ett skadligt sätt eller känsliga data kan utsättas för obehöriga parter.spridningen av automatiserade verktyg för SQL-injektioner gör SQL-injektionsattacker till en utbredd säkerhetsutmaning för Java-applikationer och för den delen praktiskt taget alla andra typer av applikationer som kan ansluta till en databas idag.

lösningen på SQL-injektionsattacker i Java är enkel nog: Se till att din app korrekt validerar inmatning och förhindrar att skadlig kod läggs till data som redan godkänts i ett formulär. Som en allmän regel och där det är möjligt, undvik dynamiska frågor för att mildra risken för SQL-injektioner i Java-applikationer. Java: s PreparedStatement-klass kan också vara till hjälp för att förhindra SQL-attacker.

Java LDAP-injektioner

injektionsattacker som utnyttjar LDAP-uttalanden (Lightweight Directory Access Protocol) representerar en annan vanlig attack på Java-applikationer. Här är inmatningsvalidering nyckeln till att förhindra attacker.

i synnerhet kan Java-utvecklare motverka de flesta typer av LDAP-injektionsattacker om de undviker LDAP-specialtecken.

andra typer av Java-injektionsattacker

Vi har redan täckt SQL-injektioner och LDAP-injektioner, men injektionsattacker i Java-applikationer slutar inte där. Anslutningssträngsinjektioner, XSS-injektioner (cross-site scripting) och andra typer av attacker är alla möjliga.

dessa typer av attacker gäller inte alla Java-applikationer-XSS är egentligen bara en allvarlig risk med webbapplikationer, till exempel-men de är en annan påminnelse om varför inmatningsvalidering är så viktig.

SecurityManager sårbarheter

SecurityManager är utformad så att du kan köra opålitliga bytecode säkert i Java-program. SecurityManager sandlådor bytecode för att förhindra attacker.

om du kan uppnå den funktionalitet du behöver utan , mildra Java säkerhetsrisker och undvika det.

detta gör SecurityManager till en bra resurs för Java-säkerhet-förutsatt att det naturligtvis fungerar korrekt. Den största risken för SecurityManager är historien om säkerhetsproblem som uppstått inom SecurityManager själv. Dessa sårbarheter tillåter ibland isolerad kod att bryta ut ur sandlådan och utföra attacker.

i viss utsträckning är hantering av säkerhetsproblem i SecurityManager och Java ett problem inte för utvecklare utan för systemadministratörer, som måste hålla Java-körtider uppdaterade. Utvecklare kan dock göra sin del och undvika sandlådor när det är möjligt. Med andra ord, lita inte blint på SecurityManager. Om du måste använda den i en applikation, använd den. Men om du kan uppnå den funktionalitet du behöver utan den, mildra Java – säkerhetsrisker och undvik den.

skadliga burkar

När en Java-applikation laddar burkar vid körning kan en hackare ibland lura applikationen att länka skadliga burkar. Detta är ett gammalt säkerhetsproblem, och Java har infört ett antal kontroller genom åren för att förhindra det.

några av dessa attackreduceringsfunktioner verkar på egen hand, men utvecklare kan dra full nytta av dem genom att underteckna burkar. På så sätt verifieras signaturer vid körning och förhindrar intrång. Programmerare kan också mildra hotet från skadliga burkar genom att begränsa åtkomstbehörigheterna för specifika klasser så att, om skadlig kod laddas, kommer naturliga säkerhetspolicyer att begränsa skadan skadlig kod kan göra.