Paano i-monitor ang pagbabago sa checkout: ano at kailan

Ang pag-monitor ng pagbabago sa checkout ay ang malaman, habang may oras pang kumilos, kapag may bahagi ng payment page na gumagana na sa paraang hindi inaprubahan ng tindahan. Kasama rito ang mga file sa server, ang mga script na nilo-load ng page, ang mga security header at, higit sa lahat, ang lumalabas sa screen ng mamimili. Iba-ibang paraan ang kailangan sa bawat layer, at walang iisang paraan na nakakakita sa lahat ng apat.

Bakit i-monitor ang payment page at hindi lang ang site

Ang checkout ang tanging page kung saan agad nagiging pera ang atake. Ang code na kumokopya ng card o nagpapalit ng QR ng Pix (ang instant payment system ng Banco Central do Brasil, ang central bank ng Brazil) ay kailangan lang gumana roon, kaya kadalasang naka-off ito sa ibang bahagi ng site. Noong Setyembre 2026, ang mga tindahan sa Brazil na tinamaan ng ganitong code ay unang nakakita ng sintomas na pangkomersyo, ang pagdami ng mga hindi itinuloy na bayad sa Pix, bago pa ang kahit anong teknikal na alerto.

Requirement din ang pag-monitor sa payment page. Mula 31 Marso 2025, hinihingi ng requirement 11.6.1 ng PCI DSS ang mekanismong nakaka-detect ng hindi awtorisadong pagbabago sa nilalaman ng page at sa mga security header, na sinusuri nang hindi bababa sa isang beses kada linggo o sa dalas na itinakda ng sariling risk analysis ng kumpanya.

Ano ang babantayan: ang apat na layer

1. Mga file sa server

Ang mga file ng platform, ng theme at ng mga plugin. Ang pagbabagong wala sa planadong publikasyon ang pinakaklasikong senyales ng pag-hack.

Ang hindi nakikita ng layer na ito: code na galing sa panlabas na address at sa browser lang umiiral.

2. Mga script na nilo-load ng page

Ang listahan ng lahat ng kinukuha ng payment page: sariling file, analytics tool, chat, ad pixel at mga script ng payment provider. Ito ang inventory na hinihingi ng requirement 6.4.3 ng PCI DSS, na may may-ari, dahilan at garantiya ng integridad para sa bawat item.

Ang hindi nakikita ng layer na ito: isang aprubadong script na nagbabago ng kilos nang hindi nagbabago ng pangalan, o isang extension sa browser ng customer.

3. Mga security header

Ang mga instruction na ipinapadala ng server sa browser kasama ng page, gaya ng policy na nagtatakda kung saan maaaring mag-load ng script at kung saan maaaring magpadala ng data. Kapag niluwagan ng isang tao ang policy na ito, bukas na ang pinto kahit walang file na nagbago.

Ang hindi nakikita ng layer na ito: atakeng gumagamit ng serbisyong pinayagan na. Noong Hunyo 2026, inilarawan ng mga researcher ang isang code na nagnanakaw ng card data na gumamit ng isang kilalang payment service bilang tuntungan, para mismong makalusot sa mga policy na nagtitiwala rito.

4. Ang ipinapakita sa screen ng customer

Ang QR ng Pix, ang text ng Pix Copia e Cola (ang payment code na text na kinokopya ng customer at idinidikit sa app ng bangko), ang linha digitável (ang numero ng boleto) ng boleto (ang Brazilian na bank payment slip), ang address ng wallet, ang form na tumatanggap ng credit card at ng debit card, at kung saan ipinapadala ng form na iyon ang data. Dito nangyayari ang scam at dito ito buong lumilitaw.

Ang hinihingi ng layer na ito: ihambing ang nasa screen sa inilabas ng tindahan, at hindi lang itala na may nagbago.

Gaano kadalas

Walang iisang dalas. Ang praktikal na tuntunin ay magtakda ng isa para sa bawat layer:

• Mga file sa server: sa bawat publikasyon at araw-araw, na may agarang alerto para sa pagbabagong wala sa publikasyon.
• Mga script at header: tuloy-tuloy, na may pagsusuri ng tao nang hindi bababa sa lingguhan, na siyang minimum ng 11.6.1.
• Screen ng customer: sa bawat pag-load ng payment page. Ang QR na pinalitan nang Martes ng 10:00 ay nakatanggap na ng pera pagsapit ng 10:01.

Mga paraan at kung ano ang nakikita ng bawat isa

• Pag-monitor ng mga file sa server. Mabuti para sa mga pag-hack na gumagalaw sa code ng tindahan. Bulag sa binubuo sa browser.
• External scan gamit ang bot. Paminsan-minsang binubuksan ng isang bot ang checkout at itinatala ang nilo-load ng page. Nakakatulong ito sa pagbuo ng inventory, pero session lang ng bot ang nakikita nito, at maaaring iba ang kilos ng malicious code sa mga bisitang mukhang automated.
• Mga ulat ng browser tungkol sa security policy. Nag-aabiso ang browser ng customer kapag may sinubukang mag-load mula sa hindi dapat. Ipinapakita nito ang mga naharang na pagtatangka, hindi ang dumaan sa isang pinayagang address.
• Monitoring script sa mismong page. Tumatakbo ito sa browser ng totoong customer at nakikita kung ano talaga ang nilo-load ng page at ang nagbago pagkatapos itong magbukas.
• Pagsusuri sa payment data. Isang hakbang lampas sa nauna: bukod sa makitang nagbago ang QR, inihahambing ito sa QR na inilabas ng tindahan at hinaharangan kapag hindi tugma.

Ang unang tatlong paraan ay nagsasabing "may nagbago". Ang huli lang ang nagsasabing "malapit nang magbayad ang customer sa maling tao".

Paano gumawa ng alertong may tumutugon

1. Itakda kung ano ang awtorisado. Kung walang listahan ng inaasahang script at destinasyon, ingay lang ang bawat alerto.
2. Paghiwalayin ang urgent at ang karaniwan. Urgent ang bagong script sa payment page at ang hindi tugmang QR. Ang pagbabago ng bersyon ng isang analytics tool ay karaniwang bagay na susuriin sa loob ng linggo.
3. Ipadala ang urgent sa taong may kakayahang kumilos. Isang channel na may on-call, hindi isang email inbox.
4. Pagsamahin ang teknikal at pangkomersyong senyales. Ang rate ng pending na Pix, ang abandonment sa checkout at ang mga reklamo ng bayad na walang order ay kasinghalaga ng alerto sa file.
5. Itabi ang ebidensya. Petsa, page, kung ano ang nagbago at sino ang nag-apruba. Ito ang hinihingi ng PCI DSS auditor at ang nakakatulong kapag ipinapaliwanag ang insidente sa customer.

Mabilis na checklist

• Listahan ng mga script sa payment page, na may may-ari at dahilan.
• Alerto para sa file na nabago nang wala sa publikasyon.
• Content security policy na may aktibong reporting.
• Monitoring sa browser ng totoong customer, hindi lang gamit ang bot.
• Pagsusuri sa QR, sa Copia e Cola, sa linha digitável at sa card form laban sa inilabas ng tindahan.
• Araw-araw na dashboard ng rate ng pending na Pix.
• Tala ng bawat inaprubahang pagbabago at ng bawat inasikasong alerto.

Para sa konteksto ng mga atakeng pinipigilan ng ganitong monitoring, basahin ang Magecart: ano ito at paano protektahan ang e-commerce. Para sa mga requirement, tingnan ang pagsunod sa PCI DSS.

Saan pumapasok ang Proteside

Sinasaklaw ng Proteside ang ikalawa at ikaapat na layer sa browser ng mamimili: pinapanatili nito ang inventory ng mga script sa payment page at sinusuri, sa bawat order, kung ang QR, ang Copia e Cola, ang linha digitável at ang card form ay ang mga inilabas ng tindahan. Kapag hindi, hinaharangan nito ang pagpapalit bago ang kumpirmasyon, inaabisuhan ang tindahan at itinatala ang kaso bilang ebidensya para sa PCI DSS. Tingnan ang paano ito gumagana.