Paturpinot pagājušā mēneša tēmu par dažādu platformu salīdzināšanu, mēs nolēmām apskatīt šajā bloga ierakstā drošības tēmu. Vispirms ir jāsaprot kādi ir galvenie drošības riski interneta veikalu platformās.


Visbiežāk sastopamie drošības riski e-komercijas platformās


1.Neatjaunināta sistēma un spraudņi

Risks: Novecojušu platformu, spraudņu vai servera programmatūru versiju izmantošana satur zināmas ievainojamības (SQL injekcija, XSS, RCE).

Novēršana: Regulāri atjaunināt platformu, spraudņus un servera programmatūru.

Ietekme, ja nenovērš: Uzbrucēji var pārņemt kontroli pār veikalu, zagt klientu un maksājumu datus.


2. Vājas paroles un nepietiekama autentifikācija

Risks: Administratora vai klientu konti tiek uzlauzti ar brute-force (kriptoanalītisks uzbrukums, kur uzbrucējs mēģina uzminēt pareizās paroles) vai credential stuffing (kiberuzbrukuma paveids, kas masveidā nozog lietotāju datus - paroles un e-pastus ar kuriem pēc tam mēģina ielogoties citās sistēmās).

Novēršana: Spēcīgas paroles, divu faktoru autentifikācija (2FA), pieslēgšanās/ ielogošanās mēģinājumu ierobežošana.

Ietekme: Neautorizēta piekļuve sistēmai, veikala kontroles zaudēšana, datu noplūde.


3. Nedroši spraudņi un moduļi

Risks: Trešo pušu paplašinājumi bieži satur ievainojamības vai ļaunprātīgu kodu.

Novēršana: Izmantot tikai uzticamu izstrādātāju spraudņus, ja iespējams, pārbaudi un pārskati kodu (šeit gan ir nepieciešamas programmēšanas zināšanas).

Ietekme: Backdoor (slēpta metode, kas ieviesta, lai apietu parasto ierīces/aplikācijas/sistēmas autentifikāciju un šifrēšanu) ievietošana sistēmā, ļaunprātīgas koda injekcijas, datu noplūde.


4. Brute-force un DoS (angļu: denial-of-service attack, latv.: pakalpojumatteices uzbrukums) uzbrukumi

Risks: Automatizēti uzbrukumi var bloķēt veikalu vai uzlauzt kontus.

Novēršana: WAF (Web Application Firewall), pieslēgšanās mēģinājumu ierobežošana, CDN ar DoS aizsardzību.

Ietekme: Veikala nepieejamība - zaudēti ieņēmumi un klientu uzticība.


5. Nepietiekama servera drošība

Risks: Neatbilstoša hostinga konfigurācija (atvērti porti, vāji iestatījumi).

Novēršana: Drošs hostings, ugunsmūris, regulārs servera audits.

Ietekme: Uzbrucēji iegūst tiešu piekļuvi datu bāzei vai failu sistēmai, radot pilnīgu veikala kompromitāciju.


6. Maksājumu datu drošības trūkumi

Risks: Kredītkaršu un citu maksājumu datu noplūde (PCI-DSS neatbilstība).

Novēršana: Izmantot uzticamus maksājumu vārtus (Swedbank, SEB, Stripe, PayPal), SSL/TLS sertifikātu, nelikt kartes datus uz sava servera.

Ietekme: Finanšu datu zādzība, reputācijas bojājums, tiesiskas sekas (piem. VDAR, PCI-DSS sodi).


7. Sociālā inženierija un pikšķerēšana

Risks: Administratoriem vai klientiem izkrāpj paroles caur e-pastu, viltus saitēm.

Novēršana: Personāla un klientu izglītošana, e-pasta filtrēšana, 2FA.

Ietekme: Neautorizēta piekļuve sistēmai, kontu pārņemšana, datu zādzība.


8. Nepietiekama datu šifrēšana un rezerves kopijas

Risks: Dati tiek pārtverti vai zaudēti uzbrukuma vai sistēmas kļūmes rezultātā.

Novēršana: HTTPS visā lapā, datu bāzes šifrēšana, regulāras rezerves kopijas (ārējās).

Ietekme: Datu noplūde, biznesa nepārtrauktības apdraudējums, nespēja atgūties pēc kiberuzbrukuma.


Pēc augstāk uzskaitītajiem visbiežāk sastopamajiem drošības riskiem, tu noteikti labāk pašlaik saproti, ka ne visi drošības jautājumi ir atkarīgi tikai no izmantotās platformas, bet to var ietekmēt arī spraudņi, servera konfigurācija un dīvainu saišu uzspiešana interneta dzīlēs vai savā e-pastā.


Lai saprastu, kura no e-komercijas platformām ir visdrošākā, ir jāskatās uz konkrētām tehnoloģijām un risinājumiem, kas ir iebūvēti platformā un vai tie var tikt uzstādīti bez iejaukšanās kodā.


Aizsardzība pret XSS uzbrukumiem

Starpvietņu skriptošana jeb XSS ir datu drošības ievainojamības paveids, kas visbiežāk skar lietojumprogrammas, t.i., uzbrukums, kas atļauj kādam ievietot ļaunprātīgu kodu (parasti JavaScript) e-veikalā.  Tas tiešā veidā neietekmē mājaslapu/interneta veikalu, bet gan gala lietotāju, kas tai pieslēdzas. Tas var izraisīt dažādas ļaunprātīgas sekas, piemēram, lietotāja sesijas sīkdatņu zādzību, lietotāja identitātes viltošanu, neatļautu darbību veikšanu lietotāja vārdā un piekļuvi konfidenciāliem datiem.


Pārbaudīsim kā četras populārākās platformas tiek ar šo galā.


OpenCart 4 – ļoti labi!

OpenCart 4 izmanto Twig veidņu sistēmu, kas automātiski kodē izejas datus. Ko tas nozīmē cilvēku valodā? Ja kāds mēģina “ievietot” nevēlamu kodu veidlapā vai komentārā, sistēma to pārvērš nekaitīgā tekstā.


Turklāt ir vērts iestatīt serverī CSP galvenes – pateicoties tām, veikals pats paziņo pārlūkprogrammai, kur tā var ielādēt skriptus un kur nevar. Praksē tas ir kā vairogs, kas saka: „Hei, nedari neko, par ko es nezinu!”.


Novērtējums: 4/5. Noklusējuma aizsardzība + iespēja nodrošināt papildus aizsardzību bez lielām izmaiņām.


Magento (Adobe Commerce) – spēcīga aizsardzība, bet…

Magento ir ļoti stabili iebūvēti mehānismi: visi lietotāja dati tiek pārbaudīti un “attīrīti” pirms to parādīšanas. Tas izmanto tādas funkcijas kā escapeHtml, kas veic šo uzdevumu.


Taču ir viens, bet… daudz kas ir atkarīgs no paplašinājumiem. Ja pievieno moduli no interneta, kas neatbilst Magento drošības noteikumiem, XSS var iekļūt, neskatoties uz spēcīgo kodolu. [1] Adobe (Magento īpašnieks) dara visu, lai to kontrolētu, bet ne visu var paredzēt.


Novērtējums: 4/5. Teorētiski laba drošība, bet ir jābūt uzmanīgam ar to, ko instalēt.


PrestaShop – šeit jābūt uzmanīgam

PrestaShop nepiedāvā tik drošu aizsardzību. Drošība galvenokārt ir atkarīga no tā, vai sistēma tiek atjaunināta un vai tiek izmantoti papildu rīki (piemēram, WAF ugunsmūris vai drošības galvenes).


Diemžēl vēsture liecina, ka XSS ir diezgan izplatīta problēma PrestaShop. Ir bijuši gadījumi (piem., CVE-2024-34716, PrestaShop 8.1.0–8.1.5), kad šāda nepilnība varēja pat attālināti pārņemt kontroli pār veikalu. [2] Protams, šīs kļūdas tiek labotas, bet, ja netiek veikti atjauninājumi, pastāv liels risks. 


Novērtējums: 3/5. Tas prasa papildu darbu un pastāvīgus atjauninājumus. Cilvēkam, kurš nav tehniski orientēts, tas var būt pārāk riskanti.


Woocommerce – atkarīgs no tā, ko uzinstalē…

WooCommerce, kā WordPress paplašinājums, izmanto tā drošības mehānismus. Un tie ir diezgan saprātīgi. WP ir tādas funkcijas kā esc_html(), esc_url() vai wp_kses(), kas nodrošina, ka lapā netiek ievietots ļaunprātīgs JavaScript kods. 


Tas ir nedaudz līdzīgi kā pārbaudīt savus pirkumus pie kases – viss, kas nonāk tīmekļa vietnē, tiek filtrēts, un nevēlamais kods tiek noraidīts.


Problēma sākas, kad esi uzinstalējis spraudni no nezināma avota vai tādu, kas ir jau divus gadus novecojis. Un tā nav tikai teorija. Saskaņā ar 2024. gada ziņojumu, 96 % drošības problēmu WordPress radīja spraudņi. [3] 


Tāpēc WooCommerce var būt drošs, bet tas ir lielā mērā atkarīgs no paša. Regulāri atjauninājumi, pārdomāta spraudņu un tēmu izvēle. Tas ir pamats. Ir vērts iestatīt arī drošības galvenes (piemēram, Content-Security-Policy), lai palielinātu aizsardzību pret XSS uzbrukumiem.


Novērtējums: 2/5. ir iespējams sevi pasargāt, bet tam ir nepieciešama izpratne un sistemātiska pieeja. Iesācējiem ir viegli kaut ko palaist garām.


Aizsardzība pret CSRF uzbrukumiem

CSRF (Cross-Site Request Forgery) jeb vietnes starppieprasījuma viltošana ir vēl viens uzbrukums, kas var izraisīt lielas nepatikšanas veikalu īpašniekiem. Īsumā: kāds izliekas par ielogojušos lietotāju un veic darbību viņa vietā, ko viņš pats nav plānojis veikt. Piemēram, mainīt piegādes adresi, atcelt pasūtījumu vai administratora lietotāja gadījumā – dzēst produktus vai mainīt paroli. 


Paskatīsimies kā ar šo situāciju tiek galā populārās platformas:


Magento – drošs, bet… 

Magento izmanto tā sauktās veidlapu atslēgas (angļu: form keys)– tie ir unikāli „zīmogi”, kas ir pievienoti veidlapām un pieprasījumiem. Serveris pārbauda, vai šī atslēga atbilst pašreizējai sesijai – ja nē, pieprasījums tiek noraidīts. Vienkārši un efektīvi.


Bet jāņem vērā: Magento tehniski ļauj šo aizsardzību izlaist, piemēram, ar pielāgotām integrācijām. Un šeit bieži rodas problēmas – kāds izveido spraudni, apiet drošības sistēmu un CSRF tāpat izkļūst cauri. [4] Tāpēc Magento lielākoties viss ir atkarīgs no izstrādātāja.


Novērtējums: 4/5. Labi pasargāts, ja nav mērķtiecīgu mēģinājumu ielauzties.


PrestaShop – kādreiz vājš, tagad labāks, bet joprojām ir riski

PrestaShop izmanto tā saucamos drošības tokenus (kodiņus, kas palīdz pārbaudīt, vai piekļuve notiek likumīgi). Agrāk ar tiem bija daudz problēmu – piemēram, 2023. gadā tika atklāta ievainojamība [5], kas ļāva izmantot iepriekšējās sesijas tokenus, lai piekļūtu administrācijas panelim. Citiem vārdiem – ja reiz biji ticis iekšā, varēji turpināt tikt arī pēc tam, kad nevajadzētu. Šo kļūdu salaboja, taču neuzticība palika.


Arī šobrīd lietotāji nereti saskaras ar kļūdu “CSRF token invalid”. Tas nozīmē, ka drošības tokens netiek atpazīts un sistēma liedz piekļuvi. Šī problēma parādās nevienmērīgi – biežāk ar atsevišķiem moduļiem vai pie konkrētiem hostinga pakalpojumu sniedzējiem. Diemžēl daļa veikalu īpašnieku izvēlas pilnībā izslēgt šo aizsardzību, nevis atrisināt problēmu, un tas samazina drošību.


Novērtējums: 3/5. Sistēma strādā, bet ir trausla – viegli sabojāt vai atslēgt svarīgu drošības elementu. Ar to jāapietas ļoti uzmanīgi.


OpenCart 4 – viegla aizsardzība, bet pareizā virzienā

OpenCart izmanto tokenus, kas pievienoti interneta adresē (piemēram, user_token). To var uztvert kā sava veida sesijas parakstu, kas apliecina, ka pieprasījumu veic īstais lietotājs. Šī pieeja galvenokārt tiek izmantota administrācijas panelī, lai aizsargātu pret pamatuzbrukumiem.


Tomēr: pilnīga un vienota aizsardzība vēl nav nodrošināta visās vietās – piemēram, klienta pusē. Administrācijas darbības lielākoties ir pasargātas, taču, ja veikals ir ļoti apjomīgs un ar daudzām funkcijām, ieteicams pašiem pievienot papildu drošības slāņus.


Novērtējums: 4/5. Aizsardzība darbojas, ikdienas lietošanai pietiekami, bet nav pilnīgi ideāla.


Woocommerce – lieliski rīki, bet viss atkarīgs no tevis

WooCommerce balstās uz WordPress “nonce” sistēmu – tie ir vienreizēji kodi, kas tiek piešķirti konkrētai lietotāja darbībai. Tos var pievienot formām, pogām vai pat saitēm. Ļoti noderīgs mehānisms, kas labi pasargā no uzbrukumiem, ja tiek lietots pareizi.


Taču atkal – spraudņi. Visa šī lieliskā aizsardzība ir tik droša, cik prasmīgi to izmanto cilvēki. Vairāk nekā 90% WordPress drošības problēmu rodas tieši spraudņu dēļ, tāpēc nav grūti uzminēt, kur ir vājais punkts. Ja spraudņi nav kvalitatīvi vai netiek regulāri atjaunināti, aizsardzība kļūst trausla.


Novērtējums: 3/5. Mehānisms pats par sevi ir lielisks, taču drošība lielā mērā ir atkarīga no spraudņu kvalitātes un to regulāras uzturēšanas.


Aizsardzība pret SQL injekcijām 

SQL injekcija ir metode, ar kuru uzbrucējs izmanto sistēmas ievainojamību. Tas mūsdienās ir vispopulārākais datorsistēmu ielaušanās veids.  Kāds no ārpuses, kas ir pietiekoši atjautīgs un zina par sistēmas ievainojamību, var ievadīt komandu (SQL kodu), kas tur nedrīkstētu būt, un rezultātā iekļūt veikala datu bāzē.


Rezultāts? Uzbrucējs var piekļūt veikala datubāzei – bet tajā glabājas viss, kas nedrīkst nonākt svešās rokās: klientu dati, pasūtījumi, paroles, un daudz citu sensitīvu lietu. 


SQL injekcija tiek uzskatīta par vienu no bīstamākajiem uzbrukumu veidiem – tā ir kā durvju atvēršana no iekšpuses, ja vien drošība nav pareizi sakārtota.


Magento – stipra aizsardzība pret SQL injekciju, bet ar vienu “bet”

Magento SQL aizsardzība strādā augstā līmenī. Tas izmanto “prepared statements” – drošu metodi datu nodošanai SQL vaicājumos. Vienkāršoti sakot, dati un komandas tiek nodoti atsevišķi, tāpēc lietotāja ievadītā informācija nevar nejauši (vai ļaunprātīgi) izmainīt vaicājuma jēgu.


Papildus tam Magento izmanto savu ORM sistēmu (tā ir kā “tulks” starp PHP kodu un datubāzi), kas automātiski padara vaicājumus drošākus.


Tomēr ir viens būtisks riska punkts: daudzi SQL uzbrukumi Magento vidē notiek caur slikti uzrakstītiem spraudņiem vai pielāgotām modifikācijām. [6] Citiem vārdiem – pamata sistēma ir ļoti droša, bet, tiklīdz tiek uzstādīti nekvalitatīvi paplašinājumi, drošība ievērojami samazinās.


Novērtējums: 4/5. Stabila un droša bāze, taču jābūt uzmanīgiem ar papildinājumiem.


Prestashop – vēsturiski riski ar SQL injekciju

Arī PrestaShop izmanto prepared statements, taču ne vienmēr un ne visur. PrestaShop ir bijuši nopietni SQL injekcijas ievainojamības gadījumi – tostarp tādi, kas ļāva nozagt maksājumu karšu datus.


Ir bijuši gadījumi, kad populārajam modulim bija tik nopietna ievainojamība, ka attālināts uzbrucējs varēja pārņemt kontroli pār veikalu. [7] Un tā kā PrestaShop ir ļoti atkarīgs no ārējiem moduļiem, risks šeit ir īpaši augsts.


Tāpēc papildus regulāriem atjauninājumiem tiek ieteikts izmantot arī Web Application Firewall (WAF), kas izslēdz ļaunprātīgus pieprasījumus pirms tie sasniedz veikalu.


Novērtējums: 3/5. Pamata aizsardzība pastāv, taču atkarība no moduļiem ievērojami palielina risku.


OpenCart 4 – drošība atkarīga no izstrādātāja

Arī OpenCart 4 atbalsta prepared statements, kas ir drošāks veids datu nodošanai datubāzei. Taču atšķirībā no citām platformām, OpenCart neuzspiež ORM izmantošanu – tas nozīmē vairāk brīvības izstrādātājam, bet vienlaikus arī lielāku risku. Ja ar kodu strādā pieredzējis izstrādātājs – sistēma ir droša. Ja strādā iesācējs vai neuzmanīgs programmētājs – viegli var parādīties drošības caurumi.


Pozitīvs aspekts ir tas, ka OpenCart 4 kods ir daudz sakārtotāks nekā iepriekšējās versijās, un arī arhitektūra uzlabota. Tas veicina drošību. Tomēr kā jau ierasts – trešo pušu paplašinājumi ir biežākais vājais punkts.


Novērtējums: 3/5. Drošība ir iespējama, bet ļoti atkarīga no tā, kā un kas sistēmu attīsta.


Woocommerce – lieliski rīki, bet riskanta ekosistēma

WooCommerce balstās uz WordPress, kur globālais $wpdb objekts un metode $wpdb->prepare() nodrošina aizsardzību. Ja tos izmanto pareizi – tiek nodrošināta stabila aizsardzība.


Problēma ir tāda, ka liela daļa papildinājumu un motīvu šo metodi neizmanto vai izmanto nepareizi. Un te atkal atgriežamies pie vecās problēmas: lieliska platforma, bet riskanta spraudņu ekosistēma.


Tāpat ir vērts izmantot WAF un veikt koda auditus – īpaši veikalos ar lielu apmeklētību.


Novērtējums: 2/5. Mehānisms pats par sevi ir uzticams, bet drošība lielā mērā atkarīga no spraudņu kvalitātes un to regulāras uzturēšanas.


Droša paroļu uzglabāšana - kas slēpjas aiz ekrāna?

Labi – mēs jau runājām par XSS, CSRF, SQL injekcijām, bet tagad pienācis laiks tēmai, kas attiecas uz pilnīgi katru veikala lietotāju: paroles.


Un šeit runa nav par to, kur klients pieraksta savu paroli (uz lapiņas vai pārlūkā), bet gan par to, ko veikals dara ar paroli servera pusē.


Jo atceries: ja veikals saglabā paroles datubāzē “tīrā veidā”, tad tas vairs nav veikals, bet gan bumba ar laika degli. 


Tāpēc paskatīsimies, kuras platformas paroles patiešām šifrē, kuras tikai izliekas to darām, un kur veikala īpašnieks var gulēt mierīgi.


Magento

Magento ir paraugmodelis, kad runa ir par paroļu uzglabāšanu. Tā izmanto bcrypt – algoritmu, kas darbojas lēni… un tieši tāpēc ļoti labi. Kāpēc? Jo lēnāks ir paroles laušanas process, jo grūtāk pat superdatoram to uzminēt.


Turklāt katrai parolei tiek pievienots savs nejaušs salt (papildu piejaukums), kas nodrošina, ka pat divas identiskas paroles datubāzē izskatās pilnīgi atšķirīgi.


Papildus var noteikt atbilstošu paroles garumu, ciparus, lielos burtus, īpašos simbolus – viss, kas nepieciešams drošībai.


Novērtējums: 5/5. Lieliski nodrošināta paroles aizsardzība.


Prestashop

Šeit situācija ir interesantāka. Vecākās PrestaShop versijas (pirms 1.7) paroles glabāja, izmantojot MD5 algoritmu – un šodien to var salauzt praktiski ar parastu mājas datoru un labu grafisko karti.


Jaunākās versijas, visticamāk, ir pārgājušas uz bcrypt, taču… nav skaidras informācijas, no kuras versijas tas noticis, kā notiek veco paroļu migrācija un vai lietotāji tiek droši “pārrakstīti” (rehash) pēc nākamās pieslēgšanās.


Tas nozīmē, ka, neskatoties uz uzlabojumiem, joprojām jābūt uzmanīgiem – īpaši, ja veikals ir migrēts no ļoti vecām versijām.


Novērtējums: 3/5. Progresējis, bet ar riskiem veco datu dēļ.


OpenCart 4

Šeit beidzot ir redzams progress. Vecākās versijas (1.x, 2.x) izmantoja SHA1, kas šodien vairs netiek uzskatīts par drošu. Taču OpenCart 4 (vismaz GitHub versijā) jau izmanto password_hash() – PHP iebūvēto funkciju, kura pēc noklusējuma balstās uz bcrypt.


Tātad, ja tavs veikals darbojas uz tīras OpenCart 4 versijas, viss liecina, ka paroles tiek glabātas pareizi. Bet, ja veikals ticis atjaunināts no vecākām versijām, jāpārliecinās, ka vecās paroles tiek pārrakstītas (rehash) pēc lietotāja pieslēgšanās. Pretējā gadījumā datubāzē var palikt vājie, vecie šifrējumi.


Novērtējums: 4/5. Droša jaunā versija, bet jāseko līdzi migrācijas procesam.


Woocommerce

WooCommerce pārņem paroļu sistēmu no WordPress – un tur tās jau ilgi droši tiek  glabātas, pateicoties mehānismam PHPass.


Labākā ziņa: WordPress 6.8 ievieš jaunu, vēl drošāku sistēmu, kas balstās uz bcrypt + SHA-384. Tas paroles laušanu padara vēl grūtāku. Turklāt paroles tiek automātiski atjaunotas uz jauno standartu jau pirmās pieslēgšanās laikā pēc atjaunināšanas.


Tas ir lielisks darbs un pierādījums, ka visa ekosistēma attīstās drošības virzienā.


Novērtējums: 5/5. Droša sistēma ar skaidru nākotnes redzējumu.


Administrācijas paneļa noklusētā ceļa maiņa – vienkāršs veids, kā palielināt drošību

Zini to sajūtu, kad mēģini atvērt durvis, bet atslēga nav tur, kur gaidīji? Tieši tā darbojas pielāgoti piekļuves ceļi administrācijas panelim.


Tas ir tā saucamais security through obscurity princips. Tas neaizstāj ne spēcīgas paroles, ne aizsardzību pret brute-force uzbrukumiem, bet dara ko svarīgu – padara grūtāku robotprogrammu piekļuvi veikala administrācijas pusei.


Apskatīsim, kā tas izskatās dažādās platformās.


Magento

Magento pilnībā atbalsta pielāgotu administrācijas paneļa adresi. Noklusējuma /admin vietā var iestatīt kaut ko mazāk acīmredzamu, piemēram /panel-shop-87.


Vēl vairāk – Magento var pievienot URL saitēm slepenās atslēgas, kas nozīmē: pat ja kāds zina ceļu, bez atslēgas tālāk netiks. Gudri!


Ceļu var mainīt gan administrācijas panelī, gan failā env.php.


Novērtējums: 5/5.


Prestashop

Arī PrestaShop ļauj to izdarīt. Pietiek vienkārši pārsaukt admin mapi uz servera, piemēram, zumparizum987. Ātri, vienkārši un darbojas.


Platforma pati atpazīst jauno nosaukumu un piedāvā pieslēgties caur jauno ceļu. Brīnumu nav, bet rezultāts ir tāds, ka roboti, kas meklē /admin, netiek klāt.


Tikai jāuzmanās, lai atjaunināšanas laikā nepārrakstītu noklusējuma mapi.


Novērtējums: 4/5.


OpenCart 4

Šeit OpenCart nopelna papildus punktus.


Jā, arī šeit var pārsaukt admin mapi (piemēram, vishum2025) un pēc tam tikai ir jākoriģē ceļi config.php un admin/config.php failos. Tātad – tāpat kā PrestaShop: ātri, manuāli, bet efektīvi.


Taču vēl svarīgāk – OpenCart 4 pēc noklusējuma pārvieto storage mapi ārpus publiskās direktorijas. Tas nozīmē, ka pagaidu dati, rezerves kopijas vai žurnālfaili neatrodas vietā, kas redzama ikvienam, bet drošākā zonā. Ļoti gudrs solis, kas samazina risku, ja kāds cenšas “pavērot” mapju struktūru.


Novērtējums: 5/5.


Woocommerce

WooCommerce darbojas uz WordPress, un tur administrācijas piekļuve vienmēr notiek caur /wp-admin vai /wp-login.php. Noklusējuma ceļu nevar mainīt bez papildu spraudņiem, piemēram, WPS Hide Login.


Šie spraudņi darbojas, bet tie tomēr ir spraudņi – tie var būt novecojuši, radīt konfliktus vai, sliktākajā gadījumā, saturēt ievainojamības. Praksē tas darbojas, bet prasa lielāku modrību.


Novērtējums: 1/5. Bez spraudņa ceļu nevar mainīt. Ar spraudni – var, bet riski pieaug.


Paplašinājumu failu atdalīšana un modularitāte — ko tas nozīmē?

Labi, pirms pievēršamies tehniskajiem jautājumiem, izskaidrosim to saprotamā valodā. Interneta veikali, tāpat kā jebkura programmatūra, ar laiku aug: pievieno jaunas funkcijas, integrācijas, maksājumu metodes, slaiderus un daudz ko citu. Bet kā to izdarīt tā, lai neizjauktu veikalu atjauninājumu laikā un neradītu haosu kodā?


Modularitāte nozīmē veidot veikalu tā, ka jaunas funkcijas var uzstādīt kā atsevišķus “blokus” (moduļus), nepieskaroties pašai sistēmas “sirdij”. Tas ļauj:

  • vieglāk atjaunināt veikalu,
  • uzturēt kārtību kodā,
  • samazināt risku, ka viena izmaiņa sabojās visu sistēmu.

Apskatīsim, kā ar to tiek galā populārākās e-komercijas platformas:


Magento

Magento ir kā lego kombinātors e-komercijas pasaulē, un modularitātes ziņā strādā gandrīz kā pēc mācību grāmatas. Katram paplašinājumam ir sava mape, piem., app/code/MyStore/Moduļa nosaukums, kas atvieglo kārtību.


Kods ir sadalīts slāņos — biznesa loģika atdalīta no skatījumiem un datubāzes. Tas ir nedaudz līdzīgi kā atdalīt virtuvi, ēdamistabu un trauku mazgājamo mašīnu – katrs dara savu darbu.


Plusi:

  • Ļoti laba koda atdalīšana,
  • Sakārtota struktūra,
  • Vieglāk izolēt kļūdas.


Mīnuss:

  • Sistēma ir sarežģīta — ne katrs izstrādātājs bez pieredzes spēs izprast šo platformu.


Novērtējums: 5/5. Lieliska modularitāte, taču ar cenu – prasīga pret izstrādātāja pieredzi.


Prestashop

PrestaShop arī balstās uz moduļiem – katram modulim ir sava struktūra, un tie ir atdalīti. Kopš 1.7 versijas platforma izmanto Symfony (izstrādātāju ietvars) un Twig veidnes. Tas nozīmē profesionālāku arhitektūru, skaidrāku sadalījumu un lielākas iespējas.


Plusi:

  • Moduļi neiejaucas sistēmas kodolā,
  • Vieglāk atjaunināt,
  • Moderna arhitektūra (Symfony, Twig).


Mīnuss:

  • Vecākās versijas bija ievērojami vājākas šajā ziņā.


Novērtējums: 4/5. Jaunās versijas ir daudz labākas, bet mantojums no vecajiem risinājumiem joprojām var būt problēma.


OpenCart 4

OpenCart 4 ir veikusi būtisku kvalitatīvu lēcienu arhitektūras un koda organizācijas ziņā. Platforma joprojām balstās uz MVCL (Model–View–Controller–Language) modeli, taču tagad papildu nodrošina skaidru sistēmas un ārējo failu atdalīšanu.


Ko tas nozīmē?

Paplašinājumi, tēmas, moduļi un integrācijas vairs nemētājas kopā ar sistēmas failiem — viss tiek ievietots extension/ direktorijā.


Priekšrocības:

  • Atjauninot kodolu, netiek pārrakstīti paplašinājumi,
  • Skaidri redzams, kas nāk no sistēmas un kas ir pievienots manuāli,
  • Kārtība un vienkāršāka atkļūdošana.


Papildu bonusi:

  • Twig veidņu dzinējs (angļu: twig template engine), kas uzlabo drošību (piem., automātiska datu aizsardzība),
  • Notikumu sistēma (events), kas ļauj mainīt veikala darbību, neiejaucoties kodolā,
  • Joprojām saglabāts admin/ un catalog/ sadalījums katram spraudnim.


Novērtējums: 5/5. Tā ir visorganizētākā OpenCart versija vēsturē.


Woocommerce

WooCommerce darbojas kā spraudnis WordPress vidē, un paplašinājumi ir vienkārši papildu spraudņi. Katram ir sava mape, kods un stils. WordPress nosaka zināmu kārtību (mapes includes/, assets/, templates/), taču nekas neliedz izstrādātājam ieviest haosu.


Plusi:

  • Ļoti elastīga pieeja,
  • Daudz papildus iespēju.


Mīnusi:

  • Spraudņu kvalitāte ļoti atšķiras,
  • Neliela sistēmas kontrole – ja spraudnis ir slikti izstrādāts, tad nekādas kvalitātes tur nebūs.


Novērtējums: 4/5. Elastība ir pluss, bet spraudņu kvalitāte un kontroles trūkums var būt risks.


Interneta veikalu drošības novērtējums - laiks kopskatam!



1. Magento – 27 no 30 punktiem

Magento ieguva visvairāk punktu. Tā ir sistēma, kas paredzēta lieliem veikaliem, lielai slodzei un augstam riskam. Tajā ir viss: XSS aizsardzība, CSRF, SQLi, aizsardzība pret brute-force uzbrukumiem, reCAPTCHA, 2FA, sistēmas sadalījumi un pat oficiāla bug bounty programma. Taču tas prasa zināšanas, cilvēkus un resursus.


Kam piemērots? Lielajiem spēlētājiem ar IT komandu un lielāku budžetu.

 

2. OpenCart 4 – 25 punkti

Pārsteigums? Tikai tiem, kas viņu nepazīst. OpenCart 4 ir veicis milzīgas izmaiņas drošības ziņā – automātiska datu apstrāde (autoescaping) ar Twig, storage direktorijas pārvietošana, pieslēgšanās mēģinājumu ierobežojums, paplašinājumu mapju sadalīšana – un tas viss sistēmā, kas joprojām ir vienkārša, ātra un atvērtā koda (tieši tāpēc mēs esam sajūsmā par šo platformu un specializējamies tajā).


Kam piemērots? Vidējiem un mazajiem uzņēmumiem, kas vēlas drošu risinājumu, bet negrib 10 spraudņus katrai funkcijai.


3. Prestashop – 20 punkti

Presta ir atvērtā koda platforma, bet tai trūkst nedaudz disciplīnas drošības jomā. Moduļi ir kā potenciāla laika bumba. Daudz iespēju, bet arī daudz ievainojamību un vēsturisku incidentu. Plus punkts – pāreja uz Symfony un Twig, taču tas nav tas pats līmenis, kas Magento vai OpenCart.


Kam piemērots? Tiem, kam jau ir veikals uz Presta un kuri spēj to labi pārvaldīt. 


4. Woocommerce – 17 punkti

WordPress + WooCommerce ir kā attiecības ar cilvēku, kam ir pagātne – viss it kā ir kārtībā, bet… spraudņi, spraudņi un vēlreiz spraudņi. 96% ievainojamību izraisa tieši spraudņi. Teorētiski var būt drošība uzņēmuma līmenī, bet pietiek ar vienu sliktu spraudni – un viss sabrūk.


Kam piemērots? Blogeriem, influenceriem vai cilvēkiem, kuri ļoti labi pārzina WordPress un zina, ko nedrīkst instalēt.


Secinājumi

Labākais līdzsvars starp drošību, vienkāršību un paplašināmību? OpenCart 4.

Tas nav pārspīlēts, neprasa milzīgus resursus un vienlaikus nodrošina ļoti stabilu aizsardzības komplektu.


OpenCart dominē arī e-komercijas platformu vidū.


Visvairāk punktu? Magento. Tas ir kā liels vilciens – var aizvest ļoti tālu, bet vajadzīgas atbilstošas sliedes un stacija.


Galu galā vissvarīgākais ir ne tikai tas, ko izvēlies, bet arī tas, kā tu to pārvaldi. Pat labākā sistēma nedarbosies, ja tu to neatjaunināsi.


Ja tev ir novecojis OpenCart veikals un vēlies to atjaunot un uzlabot drošību, sazinies ar mums un mēs tev palīdzēsim.


Rakstā izmantotās atsauces un resursi

[1] MGT-COMMERCE – “Magento XSS Protection Techniques to Prevent Data Breaches”

[2] Cybersecurity - “Severe remote code execution vulnerability in PrestaShop: Update immediately” 

[3] Security Week - “8,000 New WordPress Vulnerabilities Reported in 2024” 

[4] Adobe Developer - “Cross-site request forgery (CSRF)”

[5] CloudDefense.AI - “CVE-2023-25170 : What You Need to Know”

[6] Cloudfy - “Magento Supply Chain Attack: What It Means for B2B Ecommerce and Why SaaS Security Matters”

[7] Bleeping Computer - “Facebook PrestaShop module exploited to steal credit cards”

 

Raksta sagatavošanā izmantota Design Cart publikācijā “Interneta veikala drošība – interneta veikalu reitings pēc drošības” sniegtā informācija, kā arī vairāki Wikipedia raksti.