En brandvägg kan inte förhindra alla SQL -injektionsattacker eftersom den fungerar på nätverksnivå och inspekterar nätverkstrafik baserat på IP -adresser, portar och ibland protokoll. SQL-injektion är dock en attack på applikationsnivå. Brandväggen "ser" inte "den skadliga SQL -koden inbäddad i HTTP -begäran eller annan applikationsdata.
Här är en uppdelning:
* brandväggsbegränsningar: Brandväggar undersöker *kuvertet *för nätverkskommunikationen, inte *innehållet *. De kan blockera anslutningar från specifika IP-adresser eller baserade på portnummer (som att blockera alla anslutningar till port 3306, standard MySQL-porten), men detta är en bredborste-strategi. En sofistikerad angripare kan använda andra portar eller metoder för att kringgå dessa enkla regler. De kan inte inspektera data för skadliga SQL -kommandon.
* SQL -injektion sker inom applikationen: Attacken inträffar efter att brandväggen redan har tillåtit anslutningen. Angriparen injicerar skadlig SQL -kod i ett webbformulär eller annat inmatningsfält. Denna kod överförs sedan till databaseservern *av själva applikationen *, som brandväggen inte är medveten om. Brandväggen förstår inte sammanhanget för applikationens data.
* Data Obfuscation: Angripare kan använda tekniker för att dölja SQL -injektionskoden, vilket gör det svårare för till och med avancerade brandväggar att upptäcka. Detta kan innebära kodning eller användning av ovanliga tecken.
Kort sagt, en brandvägg är en första försvarslinje, men det är inte en silverkula mot sårbarheter på applikationsnivå som SQL Injection. Korrekt säkerhetsåtgärder för applikationsnivå, såsom parametrerade frågor, inputvalidering och utgångskodning, är avgörande för att förhindra SQL-injektion. Web Application Firewalls (WAFS) kan ge ytterligare skydd genom att inspektera applikationstrafiken för kända mönster för SQL -injektion, men även WAF:er kan inte fånga alla attacker.
