עצרו סקימרים של כרטיסי אשראי בקופה שלכם

איך סקימרים נכנסים

• תוסף או תבנית פגיעים מאפשרים לתוקף להוסיף סקריפט לדפים או למסד הנתונים שלכם.
• סקריפט של צד שלישי שאתם טוענים (צ'אט, אנליטיקה, ביקורות) נפרץ בעצמו.
• סיסמת מנהל גנובה מאפשרת למישהו להדביק סקריפט בתבנית או בתיבת „קוד מותאם אישית”.

1. רשמו כל סקריפט בקופה

רשמו כל סקריפט בדפי העגלה והקופה, מי אחראי עליו ולמה הוא נחוץ. הסירו את השאר. זה בדיוק מה שדרישה 6.4.3 של PCI DSS v4.0 מבקשת.

2. השתמשו בשדות תשלום מאורחים

שערי תשלום שמציגים את שדות הכרטיס ב-iframe משלהם (למשל Payment Element של Stripe או ה-hosted fields של PayPal) מרחיקים את מספרי הכרטיסים מהדף שלכם. סקימרים עדיין יכולים להזריק טופס מזויף, אז השאירו גם את השכבות האחרות.

3. נעלו את הקופה עם CSP

הגבילו מאיפה סקריפטים נטענים, ולא פחות חשוב, לאן הם יכולים לשלוח נתונים (connect-src, ‏form-action):

Content-Security-Policy: default-src 'self'; script-src 'self' https://js.stripe.com; frame-src https://js.stripe.com; connect-src 'self' https://api.stripe.com; form-action 'self'; object-src 'none'; base-uri 'self'

4. קבעו קבצים של צד שלישי עם SRI

לקבצים סטטיים מ-CDN, ‏Subresource Integrity גורם לדפדפן לסרב לקובץ ששונה:

<script src="https://cdn.example.com/lib.min.js"
        integrity="sha384-REPLACE_WITH_THE_FILE_HASH"
        crossorigin="anonymous"></script>

ערכות פיתוח של תשלומים שמשתנות לעיתים קרובות (כמו Stripe.js) אי אפשר לקבע כך. השתמשו בהן ב-CSP.

5. זהו שינויים

דרישה 11.6.1 של PCI DSS v4.0 מבקשת דרך לזהות שינויים לא מורשים בסקריפטים ובכותרות של דפי התשלום. הסריקה המעמיקה של HackGrade בתוכנית Pro עוקבת אחרי סקריפטי הקופה ומחפשת מקורות חדשים, שינויים, קוד מוטמע ששולח נתונים החוצה וטופסי תשלום מזויפים.

6. עצרו בדיקות כרטיסים

בוטים מנצלים קופות חלשות כדי לבדוק כרטיסים גנובים. הפעילו את כלי מניעת ההונאות של ספק התשלומים, הוסיפו CAPTCHA או הגבלת קצב לקופה, ושימו לב לגלים של הזמנות קטנות שנכשלות.