Här listas några av de säkerhetsbrister vårt penetrationstest identifierar. Varje sårbarhet inleds med en kort beskrivning följt av vad konsekvenserna kan bli. Säkerhetsbristerna är uppdelade efter hur allvarliga konsekvenserna kan bli precis som i rapporten.

SQL injection och Blind SQL Injection

SQL-injektion tillåter en angripare att exekvera SQL-kommandon på servern som han angriper.

Påverkan:

En angripare kan exekvera godtyckliga SQL-satser på det sårbara systemet. Detta kan äventyra integriteten i din databas och/eller exponera känslig information. Beroende på vilken backend-databas som används kan SQL injection sårbarheter leda till olika nivåer av data/system-åtkomst för angriparen. Det kan vara möjligt att inte bara manipulera befintliga frågor, utan att sammansluta (UNION) godtycklig data, använda subselects eller lägga till ytterligare frågor. I vissa fall kan det vara möjligt att läsa in eller skriva ut till filer eller utföra skalkommandon på det underliggande operativsystemet. Vissa SQL-servrar, exempelvis Microsoft SQL Server, innehåller lagrade och utökade förfaranden (Stored och extended procedures, funktioner i databasservern). Om en angripare kan få tillgång till dessa förfaranden kan det vara möjligt att ta över hela servern.

Läs mer under Hur Hackar Man -> SQL Injection eller klicka här.

 Cross Site Scripting (XSS) 

Cross site scripting (även kallat XSS) är en sårbarhet som gör att en angripare kan skicka skadlig kod (vanligtvis i form av Javascript) till en annan användare.
Eftersom en webbläsare inte kan veta om skriptet bör litas på eller inte, kommer det att exekvera skriptet i användarmiljön och då kommer angriparen åt cookies eller session tokens från användarens webbläsare.
Det heter XSS eftersom CSS betyder “Cascading Style Sheets”.

Påverkan:

Illvilliga användare kan injicera JavaScript, VBScript, ActiveX, HTML eller Flash i en sårbar applikation för att lura en användare i syfte att samla in data från dem.
En angripare kan stjäla session cookies och sedan ta över konton utan att veta vare sig användarnamn eller lösenord.
Det är också möjligt att modifiera innehållet på sidan som presenteras för användaren.

Läs mer under Hur Hackar Man -> Cross-site scripting (XSS) eller klicka här.

Cross site request forgery (CSRF)

Cross-Site Request forgery(CSRF) är en motsatt typ av attack. Istället för att utnyttja det förtroende som en användare har för en webbplats, utnyttjas det förtroende som en webbplats har för en användare. I fallet med XSS-attacker som vi just diskuterat, är användaren offret. I fallet CSRF, är användaren en ovetande medbrottsling.

Påverkan:

En angripare kan lägga en länk på ett forum och när någon klickar på länken kommer den användaren att skicka ett meddelande till serverforumet . Ett relativt harmlöst exempel men om användaren istället är inloggad på sin bank som inte är säkrad mot CSRF kan konsekvenserna bli mycket allvarligare. Länken kan även vara riktad mot en specifik användare via mail exempelvis.

Läs mer under Hur Hackar Man -> Cross site request forgery (CSRF) eller klicka här.

PHP injection

PHP-kodinjektion är en sårbarhet som tillåter en angripare att injicera egen kod till serversidans skriptmotor. Denna sårbarhet uppstår när en angripare kan styra hela eller en del av en inmatningssträng som matas in i ett eval () anrop. Eval kommer att exekvera argumentet som kod.

Påverkan:

Illvilliga användare kan injicera PHP-kod som kommer att exekveras på serversidan. Det är möjligt att köra systemkommandon om PHP kompileraren tillåter system() eller liknande funktioner.

Exempel som ofta förekommer i samband med PHP-kodinjektion.

PHP allow_url_fopen enabled

När allow_url_fopen är aktiverat tillåter detta direktiv datahämtning från utomstående platser (webbplats eller FTP-server).

PHP register_globals enabled

När register_globals är aktiverat kommer PHP automatiskt skapa variabler i global scope för varje värde som sätts för GET, POST eller COOKIE. Detta, i kombination med användning av variabler utan initialisering, har lett till många säkerhetsproblem.

PERL injection

Samma som PHP-injektion men skillnaden är att du injicerar Perl-kod inte PHP.

Påverkan:

Illvilliga användare kan injicera Perl-kod som kommer att exekveras på serversidan.

ASP injection 

Samma som PHP- och Perl-injektion men skillnaden är att du injicerar ASP-kod inte PHP/Perl (ASP-injektion är endast möjligt på Windows-datorer som kör IIS).

Påverkan:

Illvilliga användare kan injicera ASP-kod som kommer att exekveras på serversidan.

Server side includes (SSI) 

Server Side Includes eller SSI är ett enkelt server-side skriptspråk som används nästan uteslutande för webben. Som namnet antyder, är dess huvudsakliga användning att inkludera innehållet i en fil till en annan, via en webbserver. SSI används främst för att “klistra” innehållet i en eller flera filer till en annan. Till exempel, en fil (av något slag,.htm,.txt, etc.) som innehåller ett dagligt citat skulle kunna ingå i flera SSI-Aktiverade sidor på en webbplats genom att placera specifik kod i de önskade sidorna. Med en förändring av citat.txt filen skulle sidor innehållande kodsträngen visa de senaste dagliga citaten. Server Side Includes är användbart för att inkludera en gemensam bit kod genom en hel webbplats, till exempel en navigeringsmeny. För att en webbserver ska känna igen en SSI-aktiverad HTML-fil och utföra dess instruktioner måste filen sluta med. Shtml förlängningen. SSI-filer kan också sluta med. Shtm men det beror på serverns förmåga att känna igen förlängningen.

Påverkan:

En angripare kan köra kommandon på servern

Code execution & Command execution

Kodsårbarheter förekommer när output eller innehåll serverat från en webbapplikation kan manipuleras på ett sådant sätt att den triggar server-side kod. I vissa dåligt skrivna webbapplikationer som tillåter användare att ändra server-side filer (t.ex. genom att posta till en anslagstavla eller gästbok) är det ibland möjligt att injicera kod i skriptspråket i själva ansökan.

Påverkan:

En illvillig användare kan exekvera godtyckliga systemkommandon med behörighet från webbservern.

Läs mer under Hur Hackar Man ->Code Execution eller klicka här.

File inclusion

En angripare kan innefatta en fjärr-eller lokal fil och utföra kommandon på servern

Påverkan:

Det är möjligt för en angripare att inkludera en fil från lokala eller fjärranslutna källor och/eller exekvera godtycklig skriptkod med rättigheter från webbservern.

Directory Traversal

Katalogtraversering är en sårbarhet som tillåter hackare att komma åt begränsade kataloger och utföra kommandon utanför webbserverns rotkatalog.

Påverkan:

Genom att utnyttja katalogtraverseringssårbarheter, stiger hackare ut ur rotkatalogen och kommer åt filer i andra kataloger. Som ett resultat kan angripare granska begränsade filer eller utföra kommandon, vilket leder till fullständigt äventyrning av webbservern.

Cross Frame scripting (XFS)

Detta är en attackteknik som används för att lura en användare att tro att en falsk webbplatsinnehåll är legitima uppgifter.

Påverkan:

Hackare kan ta över en frame och genom denna utföra nätfiskeattacker.

CGI security checks

CGI-säkerhetskontroller används för att se om Common Gateway Interfacet på en webbplats är sårbart mot gamla eller nya buggar.

Påverkan:

Hackare kan utföra kommandon eller annat beroende på buggen.

Cookie attacks

Genom att injicera en anpassad HTTP-rubrik eller genom att injicera en metatagg är det möjligt att ändra de cookies som lagras i webbläsaren. Hackare kommer normalt manipulera cookiesvärden för att kunna autentisera sig på en webbplats med de förfalskade uppgifterna.

Påverkan:

Genom att utnyttja denna sårbarhet kan en angripare genomföra en “session fixation” attack. I en session fixation attack fastställer angriparen användarens sessions-ID innan användaren ens loggar in på målservern, vilket eliminerar behovet att få användarens sessions-ID efteråt.

HTTP Parameter Pollution

HPP attacker består av att injicera kodade frågesträngavgränsare i andra befintliga parametrar. Om en webbapplikation inte korrekt sanerar indata från användaren kan en hackare äventyra logiken i programmet och utföra antingen clientside eller server-side attacker.

Påverkan:

Åsidosätta befintligt hårdkodade HTTP parametrar
Ändra applikationens beteende
Åtkomst till och eventuellt utnyttja okontrollerade variabler
Kringgå verifiering av indata och WAF-regler (Web Application Firewall)

Http response splitting/CRLF injection

CRLF står för: CR(0x13)(\r) och LF(0x10)(\n). Dessa två specialtecken representerar End of line (EOL) markörer för många Internet-protokoll, inklusive, men inte begränsat till MIME (e-post), NNTP (nyhetsgrupper) och ännu viktigare HTTP. När programmerare skriver kod för webbapplikationer delar de headers baserat på var CRLF hittas. Om en angripare kan injicera sin egen CRLF sekvens i en HTTP ström, kan han illvilligt kontrollera hur en webbapplikation fungerar.
HTTP-svarsuppdelning är en ny angreppsteknik som möjliggör olika nya attacker såsom webb-cache poisoning, cross user defacement, kapning av sidor med känslig användarinformation och cross-site scripting (XSS). Angriparen skickar en enda HTTP-begäran som tvingar webbservern att bilda en utdataström, som sedan tolkas av målet som två HTTP-svar i stället för ett svar.

Påverkan:

Det är möjligt för en angripare att injicera anpassade HTTP headers. Till exempel kan en angripare injicera session cookies, förfalska mailrubriker eller köra HTML-kod. Detta kan leda till sårbarheter som XSS (cross-site scripting) eller session fixering (session fixation).

Buffer overflow

Det är nästan omöjligt att hitta buffer overflow i en webbapplikation idag men det finns fortfarande några skript som använder C \ C + + \ C #-kod där det kan användas.

Påverkan:

En angripare kan köra kommandon på servern och även få root-privilegier.

Security vulnerability in MySQL/MariaDB sql/password.c

Sergei Golubchik postade till oss-sec mailinglista (Open Source Security Mailing List) om en nyligen patched säkerhetsbrist (CVE-2012-2122) i MySQL och MariaDB-databasservrar. När en användare ansluter till MariaDB / MySQL beräknas en token (SHA över ett lösenord och en slumpmässigt vald sträng) och jämförs med det förväntade värdet. På grund av felaktig casting kan det ha hänt att en token och det förväntade värdet ansågs lika, även om memcmp() returnerade ett värde skilt från noll. I det här fallet trodde MySQL/MariaDB att lösenordet var korrekt, även när det inte var det. Eftersom protokollet använder slumpmässiga strängar, är sannolikheten att träffa felet ungefär 1/256. Vilket innebär att om någon vet ett användarnamn för att ansluta ( “root” finns nästan alltid ) kan denna ansluta med vilket lösenord som helst så länge det görs tillräckligt många gånger för att träffa buggen.

Påverkan:

~ 300 försök tar bara en bråkdel av sekund, så i princip är lösenordsskydd lönlöst.