A PHP biztonsági rései: Munkamenet-eltérítés, webhelyek közötti parancsfájlok, SQL-injekció és javításuk

Biztonság a PHP-ben

A PHP-kód írásakor nagyon fontos szem előtt tartani a következő biztonsági réseket, hogy elkerüljük a nem biztonságos kódot.

A sebezhetőségek típusai

Ezek a leggyakoribb biztonsági rések, amelyekkel találkozhat, amikor PHP-kódot ír. Az alábbiakban néhányat részletesebben megvitatunk.

  • Helyszíni kérelmek hamisítása Az alkalmazás biztonsági rése, amelyet a programozó okozott, ha nem ellenőrizte, honnan küldtek kérést - ezt a támadást egy magas jogosultságú felhasználónak küldjük, hogy magasabb szintű hozzáférést kapjon az alkalmazáshoz.
  • Helyszíni szkriptek Az alkalmazás biztonsági rése, amelyet a programozó okoz, ha a programozó nem fertőtleníti a bevitelt, mielőtt a böngészőbe bocsátaná a bemenetet (például megjegyzést írhat egy bloghoz). Általában rosszindulatú javascript futtatására használják a böngészőben olyan támadások végrehajtására, mint a munkamenet-sütik ellopása egyéb rosszindulatú tevékenységek mellett, hogy magasabb szintű jogosultságokat szerezzenek az alkalmazásban.
  • Helyi fájlok felvétele Az alkalmazás biztonsági rése, amelyet a programozó okozott, és a felhasználó által megadott fájlbevitelt igényel, és a kimenő fájl elérése előtt nem fertőtleníti a bemenetet. Ennek eredményeként egy fájl kerül fel, ahol nem kellett volna.
  • Távoli fájl befogadása Az alkalmazás biztonsági rése, amelyet a programozó okozott, és amely a felhasználó által megadott fájlbevitelt igényel, és nem fertőtleníti a bemenetet a kért fájl elérése előtt. Ez azt eredményezi, hogy egy fájlt egy távoli szerverről húznak le, és ott adják meg, ahol nem kellett volna.
  • Munkamenet-eltérítés Az a biztonsági rés, amelyet egy támadó okoz, ha hozzáférést kap a felhasználó munkamenet-azonosítójához, és képes megszemélyesíteni egy másik felhasználó fiókját. Ezt gyakran használják az adminisztrátori felhasználói fiókhoz való hozzáféréshez.
  • A munkamenet-azonosító megszerzése A munkamenet-azonosító megszerzése egy olyan biztonsági rés, amelyet a támadó okozhat, ha kitalálja a felhasználó munkamenet-azonosítóját, vagy kihasználhatja az alkalmazás vagy a felhasználó böngészőjének biztonsági réseit a munkamenet-azonosító megszerzéséhez.
  • SQL Injection Az alkalmazás biztonsági rése, amelyet a programozó okozott, ha nem fertőtlenítette a bemenetet, mielőtt az adatbázisba bekerült volna egy lekérdezésbe. Ez azt eredményezi, hogy a támadónak teljes olvasási és gyakran írási hozzáférése van az adatbázishoz. Az ilyen típusú hozzáféréssel a támadó nagyon rossz dolgokat tehet.

Most nézzünk meg néhány gyakori sebezhetőséget részletesebben.

Munkamenet-eltérítés

A munkamenet-eltérítés egy biztonsági rés, amelyet egy támadó okoz, ha hozzáférést kap a felhasználó munkamenet-azonosítójához, és képes megszemélyesíteni egy másik felhasználó fiókját. Ezt gyakran használják az adminisztrátori felhasználói fiókhoz való hozzáféréshez.

Védekezés a munkamenet-eltérítő támadások ellen a PHP-ben

A munkameneteltérítő támadások elleni védekezéshez ellenőriznie kell az aktuális felhasználó böngészőjének és helyének adatait a munkamenetről tárolt információkkal szemben. Az alábbiakban bemutatunk egy példát, amely segíthet enyhíteni a munkamenet-eltérítő támadás hatásait. A munkamenet folytatása előtt ellenőrzi az IP-címet, a felhasználói ügynököt, és ha a munkamenet lejárt, eltávolítja a munkamenetet.

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

Cross Site Scripting

A Cross Site Scripting egyfajta sebezhetőség egy webalkalmazásban, amelyet a programozó okoz, mivel a programozó nem fertőtleníti a bemenetet, mielőtt a bemenetet a webböngészőhöz adja ki (például megjegyzés egy bloghoz). Általában rosszindulatú javascript futtatására használják a webböngészőben támadások végrehajtására, például munkamenet-cookie-k ellopására más rosszindulatú műveletek mellett, hogy magasabb szintű jogosultságokat szerezzenek a webalkalmazásban.

Példa a webhelyek közötti parancsfájlok támadására

A blog lehetővé teszi a felhasználók számára, hogy HTML-címkékkel formázzák megjegyzésüket, azonban a blogot működtető szkript nem vonja le azokat a címkéket, amelyek lehetővé teszik bármely felhasználó számára, hogy javascriptet futtasson az oldalon. A támadó ezt előnyére használhatja, hogy rosszindulatú javascripteket futtasson a böngészőben. Megfertőzhetik a felhasználókat rosszindulatú programokkal, ellophatnak munkamenet-sütiket és egyebeket.

 alert('Cross Site Scripting!'); 

Webhelyének megvédése a webhelyek közötti parancsfájlok támadásától a PHP-ben

A PHP-ben két elsődleges funkció van, htmlspecialchars()és strip_tags()beépítve van arra, hogy megvédje magát a helyszíni parancsfájlok támadásaitól.

A htmlspecialchars($string)funkció megakadályozza, hogy a HTML karakterlánc HTML formátumban jelenjen meg, és egyszerű szövegként jelenítse meg a webböngészőben. htmlspecialchars () kód példa


    

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);

Az X-XSS-Protection fejléc beállítása:

A PHP-ben elküldheti a X-XSS-Protectionfejlécet, amely felszólítja a böngészőket, hogy ellenőrizzék a tükrözött Cross Site Scripting támadást, és megakadályozzák az oldal betöltését. Ez nem akadályozza meg az összes, a helyszíneken felüli parancsfájl-támadást, csak a tükrözötteket, és más módszerekkel együtt kell használni.


    

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