Lühidalt: Läbistest teie PHP rakendusele näitab, milliseid nõrkusi ründaja tegelikult ära kasutada võiks, enne kui keegi seda teeb. Koos spetsialiseerunud partneritega kontrollime rakendust ja serverit kirjalikult kokkulepitud mahus ning anname aruande prioriseeritud meetmetega. Pärast kõrvaldamist kontrollime järeltestis, kas augud on suletud.
Miks läbistest PHP rakendustele on mõistlik
PHP2Shell on näidanud, et isegi rakenduse alus, PHP ise, võib sisaldada kriitilist turvaauku. Enamik sissemurdmisi PHP rakendustesse kulgeb aga teadaolevate nõrkuste kaudu oma koodis või seadistuses: SQL-injektsioon, saidiülene skriptimine (Cross-Site-Scripting), ebaturvalised failide üleslaadimised, nõrgad sessioonid, aegunud sõltuvused või avatud haldusalad. OWASP Top 10 võtab need kategooriad kokku.
Sõltumatu pilk väljastpoolt leiab selle, mis igapäevatöös kahe silma vahele jääb. Juhtkonnale ja järelevalvele annab see töökindla aluse riskide hindamiseks ja eelarve sihipäraseks kasutamiseks. Arendajatele on see konkreetne tööloend.
Audit või läbistest: mis teile sobib?
| Vorm | Mida kontrollitakse | Sobib, kui |
|---|---|---|
| Seadistusaudit | server, PHP, veebiserver, ligipääsud, varukoopiad | soovite teada infrastruktuuri seisu |
| Koodiülevaatus (Code Review) | rakenduse lähtekood sissevaatega | on olemas oma arendused või suuremad kohandused |
| Läbistest Black-Box | rakendus väljastpoolt ilma eelteadmisteta | soovite näha välise ründaja vaadet |
| Läbistest Grey-/White-Box | rakendus testkontode või koodiga | soovite piiratud ajaga võimalikult palju leida |
Sageli on mõistlik kombinatsioon, näiteks serveri seadistusaudit koos rakenduse Grey-Box-testiga. Puhas Black-Box-test mõjub realistlikult, kuid kulutab palju aega uurimisele. Testkontode ja ülesehituse sissevaatega leiavad kontrollijad samas ajas üldjuhul rohkem nõrkusi.
Lisaks rakendusele tasub vaadata keskkonda: milline PHP versioon töötab, kas haldusliidesed on avalikult ligipääsetavad, kas varukoopiad asuvad veebikataloogis, kas sõltuvused on ajakohased? Sellised punktid kontrollime auditis kaasa, sest praktikas kaaluvad need sageli rohkem kui üksik viga koodis.
Millal on õige aeg testiks?
Läbistest annab kõige rohkem, kui see toimub rakenduse elutsüklis mõistlikus punktis. Tüüpilised põhjused on:
- enne käivitamist, uue rakenduse, poe või klienditeenindusportaali puhul
- pärast suuremaid muudatusi, näiteks uusi maksevõimalusi, liideseid või sisselogimismeetodeid
- pärast intsidenti, kui puhastamine ja karastamine on lõpetatud ning soovite sõltumatut kontrolli
- regulaarsete vahemike järel, kui kliendid, partnerid või teie riskijuhtimine seda nõuavad
Vähe mõtet on testil, kuni teadaolevad augud on lahti. Kes veel kasutab paigatamata PHP versioone, peaks kõigepealt looma baasseisu. Muidu maksab test selle eest, et kinnitada teadaolevat.
Kuidas PHP SOS konkreetselt aitab?
- Mahu määramine: Selgitame teiega, millised rakendused, serverid ja funktsioonid kontrollitakse, milline testiliik sobib ja mis on selgesõnaliselt välistatud. Tulemuseks on kirjalik tellimus ajaakna ja kontaktisikutega.
- Ettevalmistus: Testkontod, ligipääsud testkeskkonnale ja värske varukoopia tehakse kättesaadavaks. Teie veebimajutajat teavitatakse vajaduse korral, et testi ei blokeeritaks päris rünnakuna.
- Kontroll: Meie spetsialiseerunud partnerid testivad tunnustatud meetoditega, muu hulgas OWASP kategooriate järgi. Kriitilistest leidudest teatame kohe, mitte alles lõpparuandes.
- Aruandlus: Saate aruande juhtkonna kokkuvõtte ja tehnilise osaga.
- Järeltest: Pärast kõrvaldamist kontrollime leitud nõrkusi uuesti ja kinnitame, mis on suletud.
Paljusid leide saab juba ette vältida. Juhendid teemal SQL-injektsioon PHP-s, turvalised failide üleslaadimised ja sessioonid PHP-s aitavad arendajatel ette valmistuda.
Mida te saate ja mida me vajame
Aruanne sisaldab iga leitud nõrkust koos kirjelduse, mõjutatud kohaga, riskihinnangu ja konkreetse parandussoovitusega. Juhtkonna kokkuvõte seab tulemused erialasõnavarata konteksti. Pärast järeltesti saate kinnituse, millised punktid on kõrvaldatud. Ründetööriistad ega käivitatavad ekspluatatsioonid aruande osaks ei ole.
Teilt vajame:
- kirjalikku luba volitatud isikult iga testitava süsteemi kohta, ka siis, kui see asub veebimajutaja juures
- testkontosid rollidega, mida tuleb kontrollida
- testkeskkonda või nõusolekut testida live-keskkonnas ajaaknas
- tehnilist kontaktisikut testi ajal
- koodiülevaatuse puhul: ligipääsu hoidlale
Mida me ei luba
Läbistest ei leia iga auku. See on hetkeseis kokkulepitud mahus; uued funktsioonid või uued augud sõltuvustes võivad homme anda teistsuguse pildi. Me ei nimeta sertifikaate ega märke, mida meil pole, ega anna tõendeid, mis asendaksid õiguslikke kohustusi. Kas test täidab teie kohustusi näiteks NIS2 alusel, selgitage välja oma õiguse ja nõuetele vastavuse spetsialistidega.
Leidude kõrvaldamise võtame soovi korral ise enda peale või koos teie agentuuriga. Serveri ja PHP seadistuse jaoks sobib serveri karastamine.
Korduma kippuvad küsimused
Mis vahe on turvaauditil ja läbistestil?
Audit kontrollib seadistust, protsesse ja koodi nõuete ja kogemuste alusel, sageli süsteemidesse sisse vaadates. Läbistest püüab sihipäraselt ja teie loal nõrkusi ära kasutada, et näidata nende tegelikku mõju. Mõlemad täiendavad teineteist.
Kas läbistest on minu PHP rakendusele ohtlik?
Test võib süsteeme koormata või andmeid muuta. Seetõttu määratakse maht, ajaaken ja piirid eelnevalt kirjalikult ning soovitame võimalusel kasutada testkeskkonda. Värske varukoopia kuulub alati juurde.
Kas läbistest leiab kõik turvaaugud?
Ei. Test näitab nõrkusi, mis kokkulepitud mahus ja ajavahemikus leiti. See on hetkeseis ja vähendab riski, kuid ei tõenda, et rohkem auke ei ole.
Kas läbistest aitab NIS2 puhul?
Turvameetmete regulaarne kontroll on tavaline element, et täita riskijuhtimise kohustusi. Millised nõuded teie ettevõttele konkreetselt kehtivad, selgitage palun välja õiguse ja nõuetele vastavuse spetsialistidega.