PHP sigurnosne ranjivosti: otmica sesije, skriptiranje na više lokacija, SQL ubrizgavanje i kako ih popraviti

Sigurnost u PHP-u

Pri pisanju PHP koda vrlo je važno imati na umu sljedeće sigurnosne ranjivosti kako biste izbjegli pisanje nesigurnog koda.

Vrste ranjivosti

Ovo su uobičajene ranjivosti s kojima ćete se susresti prilikom pisanja PHP koda. U nastavku ćemo razmotriti nekoliko detalja.

  • Krivotvorenje zahtjeva za više web lokacija Ranjivost u aplikaciji koju je uzrokovao programer koji nije provjerio odakle je poslan zahtjev - ovaj se napad šalje korisniku visoke razine privilegija kako bi dobio pristup višoj razini aplikacije.
  • Cross Site Scripting Ranjivost u aplikaciji koju je uzrokovao programer koji nije dezinficirao unos prije iznosa unosa u preglednik (na primjer komentar na blogu). Uobičajeno se koristi za pokretanje zlonamjernog javascripta u pregledniku za izvršavanje napada poput krađe kolačića sesije, među ostalim zlonamjernim radnjama radi stjecanja privilegija više razine u aplikaciji.
  • Uključivanje lokalne datoteke Ranjivost u aplikaciji koju uzrokuje programer koji zahtijeva unos datoteke koji je pružio korisnik i koji ne dezinficira unos prije pristupa traženoj datoteci. To rezultira uključivanjem datoteke tamo gdje ne bi trebala biti.
  • Uključivanje datoteke na daljinu Ranjivost u aplikaciji koju je uzrokovao programer koji zahtijeva unos datoteke koji je pružio korisnik i koji ne dezinficira unos prije pristupa traženoj datoteci. To rezultira izvlačenjem datoteke s udaljenog poslužitelja i uključivanjem tamo gdje ne bi trebala biti.
  • Otmica sesije Ranjivost koju je prouzročio napadač koji je pristupio identifikatoru korisničke sesije i mogao koristiti račun drugog korisnika koji se lažno predstavlja oko njih. To se često koristi za dobivanje pristupa računu administrativnog korisnika.
  • Nabava identifikatora sesije Nabava identifikatora sesije je ranjivost koju uzrokuje napadač koji može pogoditi identifikator sesije korisnika ili iskoristiti ranjivosti u samoj aplikaciji ili korisnikovom pregledniku kako bi dobio identifikator sesije.
  • SQL Injection Ranjivost u aplikaciji koju je uzrokovao programer koji nije dezinficirao unos prije nego što ga je uključio u upit u bazu podataka. To dovodi do toga da napadač ima puni pristup čitanju i češće nego ne pisanju baze podataka. S ovom vrstom pristupa napadač može učiniti vrlo loše stvari.

Sada ćemo detaljnije razmotriti neke uobičajene ranjivosti.

Otmica sesije

Otmica sesije je ranjivost koju je prouzročio napadač koji je pristupio identifikatoru korisničke sesije i mogao koristiti račun drugog korisnika koji se na njega predstavlja. To se često koristi za dobivanje pristupa računu administrativnog korisnika.

Obrana od napada otmice sesije u PHP-u

Da biste se obranili od napada otmice sesije, trebate provjeriti preglednik i informacije o trenutnom korisniku u odnosu na podatke pohranjene o sesiji. Ispod je primjer implementacije koja može pomoći ublažiti učinke napada otmice sesije. Provjerava IP adresu, korisničkog agenta i je li sesija istekla uklanjanjem sesije prije nego što je nastavljena.

 ($_SESSION['lastaccess'] + 3600)) { session_unset(); session_destroy(); } else { $_SESSION['lastaccess'] = time(); }

Cross Site Scripting

Cross Site Scripting vrsta je ranjivosti u web aplikaciji koju uzrokuje programer koji ne dezinficira unos prije iznosa unosa u web preglednik (na primjer komentar na blogu). Obično se koristi za pokretanje zlonamjernog javascripta u web pregledniku za izvršavanje napada, poput krađe kolačića sesije, među ostalim zlonamjernim radnjama radi stjecanja privilegija više razine u web aplikaciji.

Primjer napada na više web lokacija

Blog omogućuje korisnicima da svoje komentare stiliziraju HTML oznakama, međutim skripta koja pokreće blog ne uklanja oznake omogućavajući bilo kojem korisniku pokretanje javascripta na stranici. Napadač to može iskoristiti u svoju korist za pokretanje zlonamjernog javascripta u pregledniku. Korisnike bi mogli zaraziti zlonamjernim softverom, ukrasti kolačiće sesije i još mnogo toga.

 alert('Cross Site Scripting!'); 

Obrana vaše web stranice od napada na skriptama u PHP-u

U PHP-u postoje dvije osnovne funkcije htmlspecialchars()i strip_tags(), ugrađene kako bi se zaštitile od napada skriptiranja na više web lokacija.

htmlspecialchars($string)Funkcija će spriječiti HTML niz od pružanja što su HTML i prikazati ga kao običan tekst u web pregledniku. primjer koda htmlspecialchars ()


    

The other approach is the strip_tags($string, $allowedtags) function which removes all HTML tags except for the HTML tags that you’ve whitelisted. It’s important to note that with the strip_tags() function you have to be more careful, this function does not prevent the user from including javascript as a link, you’ll have to sanitize that on our own.

strip_tags() code example


     

"; echo strip_tags($usercomment, $allowedtags);

Postavljanje zaglavlja X-XSS-zaštite:

U PHP-u možete poslati X-XSS-Protectionzaglavlje koje će tražilicama reći da provjere ima li odbijenog napada Cross Site Scripting i blokiraju učitavanje stranice. To ne sprječava sve napade skriptiranja na više mjesta samo one koji se odražavaju i trebaju se koristiti u kombinaciji s drugim metodama.


    

Writing your own sanitization function Another option, if you would like more control over how the sanitization works, is to write your own HTML Sanitization function, this is not recommended for PHP Beginners as a mistake would make your website vulnerable.

Defending your website from cross site scripting attacks with a Content Security Policy

An effective approach to preventing cross site scripting attacks, which may require a lot of adjustments to your web application’s design and code base, is to use a content security policy.

Set a Content Security Policy as an HTTP Header

The most common way of setting a Content Security Policy is by setting it directly in the HTTP Header. This can be done by the web server by editing it’s configuration or by sending it through PHP.

Example of a Content Security Policy set in a HTTP Header


     

Set a Content Security Policy as a Meta tags

You can include your Content Security Policy in the page’s HTML and set on a page by page basis. This method requires you to set on every page or you lose the benefit of the policy.

Example of a Content Security Policy set in a HTML Meta Tag


      SQL Injection

SQL injection is a vulnerability in the application caused by the programmer not sanitizing input before including it into a query into the database. This leads to the attacker having full read and more often than not write access to the database. With this type of access an attacker can do very bad things.

Example SQL Injection attack

The below PHP Script runs an SQL Statement to get a user’s email by ID. However the input is not sanitized making it vulnerable to SQL Injection

connect_error) { die("Connection failed: " . $conn->connect_error); } $sql = "SELECT email FROM users WHERE idemail"]; } } else { echo "no results"; } $conn->close();
SELECT email FROM users WHERE id = `$input`;

So with the above the input is not type casted (I.e. casting the input with (int) so only a number is allowed) nor escaped allowing someone to perform an SQL Injection attack - for example the URL getemailbyuserid.php?id=1'; My Query Here-- - would allow you to run arbitrary SQL queries with little effort.

Defending your website from sql injection attacks in PHP

There are a few approaches to defend your website from SQL Injection Attacks. These approaches are Whitelisting, Type Casting, and Character Escaping

Whitelisting: The whitelisting approach is used in cases where only a few inputs are expected. You can list each expected input in a PHP Switch and then have a default for invalid input. You do not have to worry about a type casting issue or a character escape bypass but the allowed input is extreamly limited. It remains an option, see the example below.


        

Type Casting: The type casting approach is commonly used for an application using numeric input. Simply cast the input with (int) $input and only a numeric value will be allowed.

Character Escaping: The character escaping approach will escape characters such as quotes and slashes provided by the user to prevent an attack. If you are using MySQL Server and the MySQLi library to access your database, the mysqli_real_escape_string($conn, $string) function will take two arguments, the MySQLi connection, and the string and will properly escape the user’s input to block an sql injection attack. The exact function you use depends on the database type and php library you are using check the php library’s documentation for more information on escaping user input.

More on PHP:

  • PHP best practices
  • Best PHP code examples
  • How to prevent a slow loris attack on a PHP server
  • How to set up a local debugging environment in PHP