Blog 24/7
ARK. E01Parametr monitoringuE-commerce · lista 87 parametrów

Koszyk odpowiada

ważność krytycznamierzonysposób sklep_koszyk

Publiczne API koszyka WooCommerce zwraca 200 i przyjmuje produkt. Błąd 500 po aktualizacji oznacza, że sklep przestał sprzedawać.

Wdrożony 01.10 (badanie profilem). Z zewnątrz przez Store API, bez składania zamówienia; próba z produktem tylko dla sklepów z listy config/sklepy.toml. Strona bez WooCommerce = nie dotyczy.

ARK. 1

WIKI

wiedza ze źródeł zewnętrznych

Artykuł o parametrze „Koszyk odpowiada” jest w przygotowaniu. Powstaje po kolei dla wszystkich 87 parametrów, każde twierdzenie z przypisem do źródła.

ARK. 2

STATS

wyniki z systemu · tylko liczby zbiorcze
TAB. 2.1Odczyty per strona—

Ten parametr nie zapisuje odczytu per strona — przebieg zostawia tylko ustalenia, więc liczby sprawdzonych stron i wyników „ok” system nie ma. Pojawią się po wdrożeniu zapisu przebiegów per strona per parametr.

TAB. 2.3Ustalenia—

Ten parametr nie otworzył jeszcze żadnego ustalenia w bazie LAB247. Pusto nie znaczy „czysto” — znaczy, że nic nie przekroczyło reguły.

TAB. 2.4Przebiegi z tym sposobem sprawdzenia—

Harmonogram nie zapisał jeszcze przebiegu ze sposobem „sklep_koszyk”. Zapis przebiegów z n8n działa od 2026-09-14.

ARK. 3

CARD

karta z kodu CREATO_PING, odczyt 01.10.2026

Jak ten parametr trafia do ClickUpa: wynik sondy to linia w subtasku 2. Pomiar, a usterka, którą otwiera — linia w subtasku 1. Podsumowanie (z identyfikatorem CWE i kategorią OWASP), skąd liczy się wskaźnik zagrożenia i status strony. Projekcja z bazy skanera odświeża oba subtaski co godzinę. Do 22.09 każde ustalenie dostawało własny subtask i status ze starego słownika (PODATNA, WARNING…) — te słowa zostały jeszcze w części opisów pomiaru niżej jako język wewnętrzny sond.

RYS. 3.1Droga parametru przez system: Koszyk odpowiada
TAB. 3.1Pomiarpliki: 10
Obszar i ważnośćE-commerce · krytyczna (E01)
Workflow i częstotliwośćskaner_badanie działa na LAB247Skaner 2.0, badanie kohorty: premium co 12 h, reszta co 24–48 h · Od 2026-10-01 zestawy kohort (premium_pelny, tani_ciezki, tani_lekki) mają tury higiena, serwer, sklep, kasa i strony (wyciek ścieżek B41, CMS po EOL B44, kluczowe podstrony S08, odnośniki kontaktowe D10); nocny pomiar wydajności (trend, waga, od 01.10 też metryki pasma W01–W04 i W07) tylko premium — u reszty prośba o pomiar zagłodziłaby nocny plan. Sklep: strona bez WooCommerce = „nie dotyczy”.
Sonda i helpersposób sklep_koszyk · CREATO_PING/helpers/sklep_check.py
Testy
  1. Badanie profilem: tura „sklep” w zestawach premium_pelny, tani_ciezki, tani_lekki i ecommerce, tylko gdy http dał ok. Testy sklepu dzielą z resztą parasola jeden termin strony: 60 s.
  2. GET /wp-json/wc/store/v1/cart z nagłówkami przeglądarki, z podążaniem za przekierowaniami; przy 404 albo odpowiedzi nie-JSON druga próba przez /?rest_route=/wc/store/v1/cart (omija blokadę /wp-json/).
  3. Kod 5xx = ustalenie sklep_koszyk_nie_dziala (powaga wysoka). Kod 401, 403, 406, 429, 451 = nie_dalo_sie_sprawdzic z przyczyną `blokada`; błąd sieci = `zrodlo_nie_odpowiada`.
  4. Kod inny niż 200 albo JSON bez pola items = nie_dalo_sie_sprawdzic z flagą `nie_sklep` — panel LAB247 pokazuje parametr jako „nie dotyczy”, a tura „kasa” jest pominięta.
  5. Lista produktów: GET products (20 pozycji, w magazynie, typ prosty, wg popularności); do kupienia = is_purchasable, w magazynie i cena > 0.
  6. Próba koszyka tylko dla domen z config/sklepy.toml [proba_koszyka] (dziś jedna): POST cart/add-item pierwszego produktu do kupienia z nagłówkiem Cart-Token, potem remove-item w bloku finally. Brak produktu albo brak Cart-Token (WooCommerce < 8.3) = próba pominięta, wynik ok.
  7. Nigdy GET /wc/store/v1/checkout z pełnym koszykiem — to założyłoby szkic zamówienia w bazie klienta.
Typ wynikuenum: ok / nie_dalo_sie_sprawdzic (z przyczyną, flaga nie_sklep) + 0 albo 1 ustalenie sklep_koszyk_nie_dziala; w wyniku zakres (odczyt albo proba_koszyka), liczba produktów do kupienia, przebieg próby
Jednostkabrak — wynik jakościowy; kod HTTP Store API w dowodzie
Próg i regułaReguła, nie próg: Store API koszyka 5xx albo próba koszyka z kodem innym niż 200/201 lub z pustym koszykiem po dodaniu = sklep_koszyk_nie_dziala (powaga wysoka przy 5xx, normalna przy innym kodzie). Timeout 15 s, połączenie 5 s — stałe w helperze.
Gdzie leżą pokrętłaCREATO_PING/helpers/sklep_check.py → TIMEOUT_S, SesjaSklepu.pusty_koszyk, SesjaSklepu.proba_store_api, koszykCREATO_PING/config/sklepy.toml → [proba_koszyka] domenyCREATO_PING/config/incident_policy.toml → [finding] sklep_koszyk_nie_dzialaCREATO_PING/skaner/scenariusze/*.toml → tura „sklep”CREATO_PING/skaner/proby.toml → [parasol] limit_strony_s
Retencja odczytówSurowy pomiar jako NIEZMIENNY wiersz tabeli `odczyty` w bazie skanera (wejście, wyjście, dowody, sha karty sondy i helpera, commit kodu) — trigger odrzuca każdą zmianę. Okno retencji z kohorty: 90 dni premium, 30 dni reszta; poza oknem zostają odczyty z werdyktem problemu, akcją albo etykietą, bo replay reguł ich potrzebuje (`skaner/retencja.py`). Do LAB247 ten kanał nie idzie (do bazy serwisu jadą dziś tylko sprawdzenia dostępności), więc poza odczytem zostaje werdykt w tabeli `werdykty` i sprawa w tabeli `sprawy`.
Znane rozbieżności
  1. Katalog obiecuje „przyjmuje produkt”, a próbę koszyka robi się tylko w sklepach z listy zgody (dziś jeden); reszta sklepów ma sprawdzone tylko to, że API pustego koszyka nie zwraca 5xx.
  2. Odpowiedź 200, która nie jest JSON-em (strona wyzwania WAF, zaślepka hostingu), daje flagę nie_sklep i „nie dotyczy” — sklep za WAF-em wygląda jak strona bez sklepu.
  3. Brak sygnału zamknięcia: po naprawie koszyka helper oddaje pustą listę ustaleń, a nie `resolved`.
kandydaci do pętli: kod a opis parametru albo specyfikacja
Karta przepisana zCREATO_PING/helpers/sklep_check.py · CREATO_PING/config/sklepy.toml · CREATO_PING/config/incident_policy.toml · CREATO_PING/helpers/security_testy.py · CREATO_PING/skaner/scenariusze/premium_pelny.toml · CREATO_PING/skaner/scenariusze/ecommerce.toml · CREATO_PING/skaner/proby.toml · CREATO_PING/skaner/latest_readings.py · CREATO_PING/skaner/usterki.toml · CREATO_PING/skaner/ocena.py · odczyt 01.10.2026
TAB. 3.2Co oznacza failtypów Findingów: 1

sklep_koszyk_nie_dziala: bramka polityki otwarta (gate=true) → sprawa w skanerze → Koszyk sklepu nie działa — sklep nie sprzedaje — waga 4 → ocena 7–8 (pomarańczowy), status strony „wysoki”, dopóki sprawa jest otwarta. Waga 4 mimo effect=warning ma w katalogu uzasadnienie: dla kupującego to jak niedziałająca strona. alert=true w polityce nie jest czytane przez skaner — o mailu decyduje osobny zakres w skaner/akcje.toml. Helper nie wysyła sygnału zamknięcia.

KodFindingSeverityPewnośćSkutekFinding / alarmWaga → ocenaCo zrobić
E01.01Koszyk sklepu nie działa — sklep nie sprzedajesklep_koszyk_nie_dzialaWysoka—usterka niekrytycznatak / —waga 4 → ocena 7–8 (pomarańczowy)—
TAB. 3.3E01.01 · Koszyk sklepu nie działa — sklep nie sprzedajewersja 2 · 01.10.2026
Kod i kluczE01.01 · sklep_koszyk_nie_dziala → shop_cart_broken (klucz angielski przyjęty 01.10; skaner nadaje jeszcze stary) · w tabeli typów
Co znaczyopis do opracowania
Kiedy powstajeGET Store API /wc/store/v1/cart zwraca kod ≥ 500 (severity high). Tylko dla domen z proba_koszyka: add-item Cart-Token nie zwraca 200/201 albo items_count jest pusty.Próba koszyka: linia 334. Kody 401/403/406/429/451 oraz odpowiedź niebędąca JSON-em koszyka dają nie_dalo_sie_sprawdzic.
Severity · pewnośćWysoka
Skutek dla stronyusterka niekrytyczna · zakłada Finding
Waga → ocenawaga 4 → ocena 7–8 (pomarańczowy)
KlasyfikacjaOCSF 1.9.0: poza klasami Findingu
Rekord OCSFfinding_info.analytic.uid = "E01.01" · analytic.name = "shop_cart_broken" · finding_info.types = ["E01 Koszyk odpowiada"]
Co zrobić—
Wersje typu
  1. v1 · 01.10.2026 — kod E01.01 nadany (finding-codes.ts)
  2. v2 · 01.10.2026 — parametr z „zaplanowany” na wdrożony: sonda działa w profilach skanowania kohort (badanie), wyniki trafiają do LAB247 (doc/stan.md 2026-10-01 (6))
ARK. 4

LOOP

bez pętli
RYS. 4.1Pętla parametru — sześć etapów
TAB. 4.1Trafność, 30 dnialarmy · prawdziwe · fałszywe · bez rozstrzygnięcia

Trafności jeszcze nie liczymy: zamknięcie subtaska nie niesie dziś werdyktu (prawdziwy / fałszywy / nie dało się sprawdzić). Cztery liczby pojawią się, gdy każde zamknięcie dostanie werdykt — to warunek startu pętli 1.

TAB. 4.2Pętle—

Ten parametr nie przeszedł jeszcze żadnej pętli. Kolejność po pierwszych pięciu grupach ustali miara trafności.

Blog 24/7
14.11Osaka: atak na serwis Arara ujawnił ponad milion adresów e-mail mieszkańcówtherecord.media14.11ArcticRAT przejmuje telefony z Androidem i przez AI szuka danych finansowych w SMS-achdarkreading.com14.11Zespół Białego Domu ds. AI chce ulg dla firm po cyberatakach z użyciem AIcybersecuritydive.com14.11Platformy AI automatyzują ataki, Talos widzi w sieci ponad 700 instancji PentAGIblog.talosintelligence.com14.11FBI ostrzega przed Artex, platformą AI, która automatyzuje włamaniatherecord.media13.11Ataki Mior i Skyfall odczytują pamięć maszyn wirtualnych chronionych AMD SEV-SNPthehackernews.com13.11Gootloader otworzył drogę do 44 ataków ransomware, straty 28,8 mln dolarówtherecord.media13.11PostgreSQL łata 52 luki, w tym CVE-2026-6460 pozwalającą wykonać kod na serwerzethehackernews.com13.11Autopay potwierdza cyberatak i nieautoryzowany dostęp do części danych płatnościsekurak.pl13.11University of Texas at Arlington potwierdza kradzież danych po ataku gangu Qilintherecord.media