secure coding (tsz. secure codings)
A modern alkalmazások folyamatosan ki vannak téve kibertámadásoknak: SQL injection, cross-site scripting (XSS), buffer overflow, remote code execution (RCE), privilege escalation, stb. A nem biztonságos kód könnyen kiaknázható lehet, és súlyos adatvédelmi vagy rendszerintegritási problémákat okozhat. A secure coding célja ezek megelőzése.
Ha egy webalkalmazás nem ellenőrzi a bemeneti adatokat, akkor egy támadó SQL kódot illeszthet be, és adatokat lophat el az adatbázisból.
Minden külső adat potenciálisan veszélyes. A bemeneti adatokat mindig érvényesíteni kell – típus, hossz, tartalom, formátum alapján.
Helyes példa C++-ban:
if (userInput.length() < 30 && std::all_of(userInput.begin(), userInput.end(), ::isalnum)) {
process(userInput);
}
Az adatok kimenet előtti escape-elése megakadályozza a szkriptek vagy speciális karakterek nem kívánt futtatását (pl. HTML vagy JavaScript esetén).
A program csak a legszükségesebb jogosultságokkal fusson – így, ha egy komponens sérül, korlátozott károkat okozhat.
A hibakezelés során soha ne tárjuk fel az érzékeny információkat (pl. stack trace, adatbázis hibák). A hibaüzenetek legyenek felhasználóbarátok és ne áruljanak el belső részleteket.
Alapértelmezett beállításként a rendszer legyen biztonságos, ne nyitott vagy engedékeny.
A memóriaterület túlírása, ami rendszerösszeomlást vagy kódfuttatást okozhat.
Védekezés:
strncpy a strcpy helyett)
Támadó SQL parancsot illeszt be az adatbázis lekérdezésbe.
Védekezés:
Helytelen példa:
"SELECT * FROM users WHERE username = '" + user + "';"
Helyes példa (C++ + SQLite):
sqlite3_prepare_v2(db, "SELECT * FROM users WHERE username = ?", -1, &stmt, 0);
sqlite3_bind_text(stmt, 1, user.c_str(), -1, SQLITE_TRANSIENT);
Támadó szkriptet juttat el a felhasználó böngészőjébe.
Védekezés:
Soha ne tároljunk jelszót, API kulcsot a forráskódban.
Megoldás:
Ha a támadó manipulálni tudja a deszerializált adatot, akkor akár távoli kódvégrehajtást is elérhet.
Megoldás:
A jól strukturált, tiszta kód segíti a biztonságos működést. A bonyolult, “spagetti” kód nagyobb eséllyel tartalmaz hibát.
A peer review kötelező. Több szem többet lát, különösen biztonsági szempontból.
Unit tesztek, integrációs tesztek segítenek észrevenni regressziókat vagy újonnan bevezetett sebezhetőségeket.
A biztonsági hibák gyakran nyílt könyvtárakból származnak. Követni kell a függőségek verzióját, és időben javítani a sebezhetőségeket.
Számos iparági ajánlás létezik:
A harmadik féltől származó kód kockázatot jelent.
Ajánlások:
vcpkg.json, conanfile.txt)
char name;
strcpy(name, input); // buffer overflow lehetséges
char name;
strncpy(name, input, sizeof(name) - 1);
name = '\0';
A secure coding nem egy eszköz, hanem egy szemlélet. A fejlesztői gondolkodás részeként kell kezelni. A sebezhetőségek nem mindig a rossz szándékból erednek, hanem gyakran figyelmetlenségből vagy hiányos tudásból. A biztonságos kódolás célja, hogy ezt a kockázatot minimalizálja. Egy biztonságos program mindig kiszámíthatóan viselkedik, védi az adatokat, és ellenáll a támadásoknak – ez az, amit minden fejlesztőnek célként kell kitűznie.
