Vulnerabilities

מהי הזרקת SQL (SQLi)?

הזרקת SQL (SQLi) היא סוג של התקפה שבה תוקפים מכניסים פקודת SQL זדונית לשדה קלט כדי לתמרן את מסד הנתונים.

מהי הזרקת SQL (SQLi)?

הזרקת SQL (SQLi) היא סוג של התקפה שבה תוקפים מזינים פקודת SQL זדונית לשדה קלט כדי לתמרן את בסיס הנתונים.

התקפה זו מכוונת ליישומים שאינם מטפלים כראוי באימות, קלט משתמש, ומאפשרים גישה לא מורשית לנתונים רגישים כגון סיסמאות או פרטי כרטיס אשראי, וכו’.

כיצד פועלת הזרקת SQL

כאשר יישום כולל ישירות קלט משתמש בשאילתת בסיס נתונים ללא אימות מתאים, תוקפים יכולים לשנות את התנהגות השאילתה כדי להזין פקודת SQL זדונית.

לדוגמה:

SELECT * FROM users WHERE username = 'admin' AND password = '12345';

תוקף יכול להזין:

' OR '1'='1

מה שמוביל ל:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '';

זה תמיד מחזיר אמת, ומעניק גישה לא מורשית.

מדוע הזרקת SQL חשובה באבטחת סייבר

הזרקת SQL היא הטכניקה המסוכנת והוותיקה ביותר באבטחת סייבר. סוג זה של התקפה מופיע בעקביות ברשימת ה-OWASP Top 10.

אפילו פגיעויות קטנות מאפשרות לתוקף ל:

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

סוגים נפוצים של הזרקת SQL

  • SQLi קלאסי : הזרקה ישירה דרך טפסי אינטרנט או פרמטרים ב-URL.
  • SQLi עיוור : תוקפים מסיקים מידע על בסיס הנתונים בעקיפין (למשל, דרך הודעות שגיאה או זמן תגובה).
  • SQLi מבוסס איחוד : משתמש באופרטור UNION כדי לשלב תוצאות ממספר שאילתות.
  • SQLi מבוסס שגיאה : מסתמך על הודעות שגיאה של בסיס הנתונים כדי לחלץ מידע.
  • SQLi עיוור מבוסס זמן : מנצל עיכובי תגובה של השרת כדי לנחש תוצאות שאילתה.

כיצד למנוע הזרקת SQL

1. שימוש בשאילתות פרמטריות (הצהרות מוכנות)

ודא שפקודות SQL מתייחסות לקלט משתמש כנתונים, לא כקוד ניתן לביצוע.

cursor.execute("SELECT * FROM users WHERE username = ?", (username,))

2. אימות וניקוי קלט

אמת את כל הקלט מהמשתמשים, אפשר רק תווים צפויים.

3. שימוש במסגרות ORM

מסגרות כמו Prisma, Hibernate, וכו’, מפחיתות את הטיפול הישיר ב-SQL.

4. עקרון המינימום של הרשאות

הגבל הרשאות משתמש, תן רק את ההרשאות הנדרשות.

5. בדיקות אבטחה סדירות

השתמש בכלי בדיקות אבטחת יישומים כמו SAST, DAST או IAST כדי לזהות פגמי הזרקה מוקדם.

דוגמה בעולם האמיתי

אתר חנות מקוונת סבל מפריצה שבה תוקפים השתמשו בהזרקת SQL בטופס כניסה כדי לחלץ פרטי כרטיסי אשראי מהמסד נתונים שלו.

מונחים קשורים

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

Teams with fewer than 50 developers: start a 14-day Trial instead of booking a demo. Start a 14-day Trial →

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)