Fórumok
Hello,
Adott egy Apache + Modsecurity 2 kombó. Teszi is a dolgát úgy ahogy kell, viszont jött egy olyan ügyfél oldali igény, hogy szeretne egy saját fejlesztésű HTML editort használni, ami mentésnél mindig modsec szabályba ütközik. Ennek nyilván így is kell lennie, mivel a modsec pont arra van, hogy az efféle huncutságokat megfogja. Az (nem) megoldás, hogy kikapcsolom a szóban forgó szabályokat a mappára/oldalra, de ezt hogy lehet szebben megcsinálni, hogy ne a szabályrendszert csorbítsam?
Előre is köszönöm
Hozzászólások
Sehogy. A program olyan műveletet akar végezni, ami szabályba ütközik, ha azt akarod, hogy működjön a program, akkor ki kell kapcsolni a szabályt.
Alternatívaként azt tudnám még esetleg elképzelni, de ehhez az ügyfél is kell, hogy átírják a HTML szerkesztőt úgy, hogy ne ütközzön szabályba. De erre nem sok esélyt látok (bár nem tudom, pontosan milyen szabályról van szó), végső soron HTML fájlokat akar menteni a webszerverre, amit aztán ki kell szolgálni a webszerveren keresztül, és hát akárhogy is nézem, ezt bizony jó, hogy szűri a modsec. Esetleg azt tudom elképzelni, hogy a proggijuk nem direktben fut, hanem egy helyi webszerveren, ahonnan felscp-zik a szerkesztő által lementett fájlokat (ekkor ugyanis nem megy keresztül az apache-on és modsec-en, de ez alapjaiban más workflow-t eredményez).
Szóval szerintem vagy lebeszélitek az ügyfelet, vagy a mappájára kikapcsolod a kérdéses szabályt, más alternatívát nem nagyon látok. Ha egyik sem, akkor marad az scp-s kerülőmegoldás, de az meg lehet, nekik nem lesz jó.
ps: scp helyett megoldás lehet még egy vpn-ben futó rsync az ő helyi szerverük és a ti neten lógó szerveretek között, az talán kicsit kényelmesebb lesz nekik (csak várni kell, és előbb-utóbb magától "felkerül" a szerkesztett tartalmuk, nem kell kézzel parancsot futtatni). De a lényeg itt is az, hogy nem direktben fut a HTML szerkesztőjük a szervereteken.
Lehet, hogy "csak" simán egy form, ami post-tal tolná föl a tartalmat, és abban a post hívásban van valami csúnyaság.
Hát ja. Nem tudjuk, hogy működik a program, és azt sem, mi az a szabály, amin megakad, így elég nehéz bármi konkrétumot írni.
Annyi bizonyos, ahhoz, hogy menjen direktben a szerveren, vagy a programon kell módosítani, vagy a szabályt kell kikapcsolni. Ha egyik sem, akkor marad az a kerülőmegoldás, hogy nem direktben fut a szerveren.
Az ilyen editor a kliensen futó js motyó, ami a "mentés" során (ha jól nevelt jószág) sima "POST"-ban küldi fel a kész tartalmat (A GET idempotens, nem való erre), és vélhetően annak a POST-nak a paraméterezése akad fenn a szűrésen. Meg kell nézni böngészőben, hogy amikor rányomnak a mentésre/arra a funkcióra, ami nemműködik, mit és hogyan próbál kommunikálni a böngésző a szerverrel - illetve a waf-ban be kell állítani részletesebb naplózást a teszten, a hibakeresés idejére.
Használhat még PUT-ot is, amit kifejezetten erre találtak ki (bár tény, hogy ez nem túl valószínű, mert általában nem értenek hozzá, csak a POST-ról hallott a webfejlesztők többsége). De még POST-on belül is van többféle megoldás, lehet text field vagy file field encoded is. Az is lehet, hogy magába a mezőtartalomba kerül valami, ami nem tetszik neki, és nem is konkrétan a paraméterezés vagy a kódolás a ludas. Ekkor valóban megoldás lehet a base64 beiktatása a tartalomra (baromira nem hatékony, de működő megoldás, már ha a mezőértéken akad fenn és nem a küldés módján).
Egyetértek, tényleg tudni kéne, milyen szabályon pontosan mi akad fent, hogy többet mondhassunk. Így most csak vakon tapogatózunk.
Mi ckeditorral jártunk úgy, hogy az általa felküldött html kód zanzára ugrott a mod-security. A fejlesztők megcsavarták, hogy valami böngésző oldali megoldással base64-gyel kódoltál, szerver oldalon visszaforgatták. Így átment.
Aztán ha olyanba futottunk, hogy sehogy nem volt trükk, akkor _azt_ az 1 szabályt _azon_ a mappán/fájlon kikapcsoltuk.
nem ertek hozza, de:
ez kombo a direk modositast tiltjam kivülröl, ha jolertem.
miert nem valami repon (git, etc.) keresztül managelik a fileokat?
Ha a böngészőben futó js-es editor által küldött get/post/satöbbi sz@r, és a modsecurity megfogja, akkor teljesen mindegy, honnan küldi, sz@r marad, és el fog hasalni a modsecurity-n. Nem, "bentről" sem jó ötlet tágra nyitni a kaput - egyrészt, mert bentről is bekerülhet disznóság, másrészt meg azzal bonyolultabb konfigot kell kezelni (A "csak egy kivétel" is bonyolultabb konfigot jelent...)
Ahogy mondani szoktam, ha választhatok, hogy üzemeltetőként alszom nyugodtan, és a fejlesztőnek kell miatta szívni, vagy a fejlesztőnek lesz kevesebb munkája, nekem meg egy potenciálisan lukas rendszerem, akkor én az elsőt választom...
Nem, nem mindegy. A kolléga azt javasolja a git-tel, amit én is, hogy egy másik csatornán tolják fel a tartalmat, olyanon, ami megkerüli az apache-ot és a modsec-et. Ha nem megy át az apache-on, akkor nem lesz, ami megfogja. (Én mondjuk rsync-et használnék erre, és nem git-et, de ez már csak technikai megvalósítás részletkérdése. A lényeg, hogy másik csatorna, azaz nem direktben fut a HTML szerkesztő a szerveren).
ez kombo a direk modositast tiltjam kivülröl, ha jolertem.
Nem. Semmilyen fájl módosítást nem figyel, ez a bejövő adatokat szűri. Ez nem antivírus. Tegyük fel van egy WYSIWYG szerkesztőd, amiben a kezelő megformázza a tartalmat (a háttérben ez egy HTML), amit elküld POST-al a weboldalnak hogy mentse el az adatbázisba. Ha ez a HTML kód gyanús részletet tartalmaz amire a WAF ugrik, akkor eldobja a kérést. Neki semmi köze ahhoz hogy mit csinálsz majd azzal az adattal, az ő dolga hogy el se jusson az alkalmazásig. Benne van a nevében: Web Application Firewall.
Na és honnan tudod, hogy nem jogos-e? Nem tudjuk, hogy fals pozitív-e, vagy valóban indokolt, hogy ugrik rá. Én továbbra is azt javaslom, ha megoldható, le kell ülni a HTML szerkesztő készítőivel, és megbeszélni velük, ne küldjenek olyant, amire ugrik a modsec. Persze ehhez tudni kéne először, mi is az.
Az is lehet, hogy nem is adatbázisba mentődik a cucc, hanem file upload a query, és fájlba akarna menteni, és erre ugrik a modsec. Láttam már ilyen szerkesztőt is, és ilyen modsec szabályt is.
Egyébként valójában miért nem? A modsec gyak egy fancy tűzfal, a dolga a szemét kint tartása. Ha valamiről tudjuk, hogy az ott szándékosan olyan, akkor az nem lesz "rossz" csak azért, mert a modsec alapból megfogná. Le kell szűkíteni a valós használatra a szabályt amennyire lehet, meg nyilván, ilyenkor tudni kell róla, hogy az ott egy támadási felület, és kifejezett figyelemmel kell lenni rá szerver oldalon is. Sőt, azt is lehet, hogy hát csináljatok már olyat, ami nem csinálja ezt-meg-ezt-meg-ezt, ha lehet, mert jellemző támadó eszköz, de azért ne csináljunk úgy már, mintha minden eredendően bűn volna, amit a modsec megfog.
A kikapcsolt rule nem csak "azt ott, ami szándékosan olyan" nem fogja meg...
Ehhez a kijelentéshez tudni kéne, mi van abban a ruleban :)
+1 annak a gondolatnak, hogy meg kellene nézni, milyen szabályba miért ütközik micsoda.
Ez az egyik, később még kikeresek pár tipikusat
# [ PHP Functions: Variable Function Prevent Bypass ]
#
# Referring to https://www.secjuice.com/php-rce-bypass-filters-sanitization-waf/
# the rule 933180 could be bypassed by using the following payloads:
#
# - (system)('uname')
# - (sy.(st).em)('uname')
# - (string)"system"('uname')
# - define('x', 'sys' . 'tem');(x)/* comment */('uname')
# - $y = 'sys'.'tem';($y)('uname')
# - define('z', [['sys' .'tem']]);(z)[0][0]('uname');
# - (system)(ls)
# - (/**/system)(ls/**/);
# - (['system'])[0]('uname');
# - (++[++system++][++0++])++{/*dsasd*/0}++(++ls++);
#
# This rule blocks all payloads above and avoids to block values like:
#
# - [ACME] this is a test (just a test)
# - Test (with two) rounded (brackets)
#
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "@rx (?:(?:\(|\[)[a-zA-Z0-9_.$\"'\[\](){}/*\s]+(?:\)|\])[0-9_.$\"'\[\](){}/*\s]*\([a-zA-Z0-9_.$\"'\[\](){}/*\s].*\)|\([\s]*string[\s]*\)[\s]*(?:\"|'))" \
"id:933210,\
phase:2,\
block,\
capture,\
t:none,t:urlDecode,t:replaceComments,t:compressWhitespace,\
msg:'PHP Injection Attack: Variable Function Call Found',\
logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
tag:'application-multi',\
tag:'language-php',\
tag:'platform-multi',\
tag:'attack-injection-php',\
tag:'paranoia-level/1',\
tag:'OWASP_CRS',\
tag:'OWASP_CRS/WEB_ATTACK/PHP_INJECTION',\
tag:'OWASP_TOP_10/A1',\
ctl:auditLogParts=+E,\
ver:'OWASP_CRS/3.2.0',\
severity:'CRITICAL',\
setvar:'tx.php_injection_score=+%{tx.critical_anomaly_score}',\
setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"
SecRule TX:EXECUTING_PARANOIA_LEVEL "@lt 2" "id:933013,phase:1,pass,nolog,skipAfter:END-REQUEST-933-APPLICATION-ATTACK-PHP"
SecRule TX:EXECUTING_PARANOIA_LEVEL "@lt 2" "id:933014,phase:2,pass,nolog,skipAfter:END-REQUEST-933-APPLICATION-ATTACK-PHP"
Aláírás _Franko_ miatt törölve.
Jákub egy .
neut @