אבטחו את מערכת ה-MCP שלכם: 11 סיכונים נפוצים וכיצד להתגונן מפניהם

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

Diagram of how MCP works: the MCP host (the AI app) sends tool requests through an MCP client to an MCP server, which offers its tools and returns results to the host.

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

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

יש צעדים רבים שאנשים פרטיים וארגונים יכולים לנקוט כדי להבטיח שהמערכות שלהם מוגנות, והפרוטוקולים צריכים תמיד להיות מותאמים ליכולות ולנתונים ששרתי ה-MCP המחוברים עלולים לחשוף.

מהו MCP ומהי אבטחת MCP?

Model Context Protocol (MCP) הוא תקן פתוח שיצרה Anthropic לחיבור אפליקציות מבוססות LLM (או מארחים) למערכות חיצוניות.

יש שלושה רכיבי ליבה במערכת MCP: המארח, הלקוח והשרת. המארח, שהוא לעיתים קרובות עוזר AI, מתחבר לשרת MCP חיצוני באמצעות לקוח. לאחר מכן הוא יכול לשלוח בקשות להפעלת פונקציונליות חיצונית (כלים), לאחזור נתונים (משאבים) או לקבלת הנחיות (prompts) שיתווספו לחלון ההקשר של ה-LLM.

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

גם בעיות מוכרות שאינן ייחודיות ל-MCP, כמו הזרקת הנחיות, אימות חלש ושילובים לא בטוחים של צד שלישי, יוצרות בעיות. כמו בכל מערכת מחשוב, MCP נשען על שילוב של פרוטוקולים נוהליים, כמו שימוש בשרתים מהימנים בלבד, ובקרות טכניות, כמו שערי API, לצורך הגנה.

עד כמה חמורים האיומים על MCP?

MCP הפך במהירות לטכנולוגיית LLM פופולרית, וארגונים רבים ואפליקציות צרכניות רבות משתמשים בו. מכיוון ששרתי MCP הם תוכנות שנכתבו בקוד, יש בהם פגיעויות כמו בכל אפליקציה אחרת.

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

איום מס' 1: הזרקת הנחיות עקיפה

תוקף יכול להטמיע הוראות המיועדות ל-LLM בתוך מסמך, דף אינטרנט או פלט של כלי ששרת MCP מחזיר. אם המארח מוסיף את התוכן הזה לחלון ההקשר, קיימת אפשרות שה-LLM יטעה לחשוב שאלה הוראות אמיתיות.

יתרה מזאת, ההוראות האלה עשויות להיראות לגיטימיות במבט ראשון. לדוגמה, פנייה לתמיכה שאוחזרה עשויה להורות ל-LLM לייצא רשומות לקוחות רגישות לפני יצירת תשובה.

כיצד להתגונן מפני הזרקת הנחיות עקיפה

בדרך כלל יש לטפל בהזרקות הנחיות ברמת המארח. יש לסמן תוכן חיצוני כלא מהימן, ובקשות למידע רגיש צריכות לחייב אישור מושכל מאדם המעורב בתהליך (human in the loop). בדיקות אבטחה שכוללות קריאה למסמכים או לנתונים זדוניים כדי לבחון כיצד המארח וה-LLM מגיבים יכולות גם הן לעזור.

איום מס' 2: הרעלת כלים ומשיכות שטיח (rug pulls)

במתקפת הרעלת כלים, קוד זדוני מתווסף לתיאור או לסכמה של כלי MCP. הדבר עלול להשפיע על ה-LLM בשלב הגילוי, כאשר MCP חושף לראשונה את הכלים הזמינים.

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

כיצד להתגונן מפני הרעלת כלים ומשיכות שטיח

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

איום מס' 3: הרשאות מופרזות

נפוץ שמשתמשים מעניקים לשרתי MCP ולמודלי LLM מחוברים (דרך המארח) יותר הרשאות מהנדרש למשימה. לדוגמה, הרשאות כתיבה כשהרשאת קריאה בלבד הייתה מספיקה, או גישה מלאה למערכת קבצים פנימית (כמו Google Drive).

זחילת הרשאות נרחבת כזו עלולה להגדיל את רדיוס הפגיעה של פגיעויות אחרות, כמו קריאות זדוניות לכלים. נפוץ שהרשאות "מצטברות" ככל שמשתמשים מעניקים זכויות גישה במהלך העבודה היומיומית שלהם עם כלי AI בארגון (הצטברות הרשאות).

כיצד להתגונן מפני הרשאות מופרזות

הדרך הישירה ביותר להתגונן מפני בעיה זו היא להגביל הרשאות והיקפי OAuth (קריאה, כתיבה, גישה מלאה וכו'). אישורי משתמשים, במיוחד עבור פעולות רגישות, הם חלק חשוב מכך, אבל יש לשלוט בהרשאות גם ברמת המערכת (מערכת ההפעלה, מארח ה-MCP והשרת).

איום מס' 4: אימות והרשאה חלשים

אימות מוודא את זהותם של משתמשים או אפליקציות שמתחברים לשרת MCP. הרשאה קובעת לאילו כלים ומשאבים הם יכולים לגשת.

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

כיצד להתגונן מפני אימות והרשאה חלשים

אימות מבוסס OAuth לשרתי MCP מרוחקים, טוקנים קצרי חיים ובקרת גישה מבוססת תפקידים (RBAC) הם כולם אמצעים שעוזרים לצמצם את הסיכון של הרשאה חלשה. גישה מבוססת תפקידים שימושית מפני שהיא מונעת ממשתמשים לגשת לנתונים ולכלים מעבר להרשאות שלהם, גם אם לשרת עצמו יש גישה.

איום מס' 5: דליפה ושימוש לרעה בפרטי גישה

שרתי MCP משתמשים באופן שגרתי בפרטי גישה כמו מפתחות API וטוקני גישה של OAuth כדי להתחבר לשירותים חיצוניים. אם הם נחשפים או משמשים לרעה, תוקפים יכולים להשיג גישה לנתונים ולפונקציונליות רגישים.

דוגמה אחת היא העברת טוקנים (token passthrough), שבה שרת MCP מעביר טוקן גישה לשירות אחר בלי לוודא שהוא אכן מיועד לשירות המקבל. הדבר עלול בתורו לגרום לדליפה אם לשירות המקבל אין הגנות מספקות.

כיצד להתגונן מפני דליפה ושימוש לרעה בפרטי גישה

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

איום מס' 6: מתקפות "הסגן המבולבל" (Confused Deputy)

מתקפת "סגן מבולבל" (confused deputy) מתרחשת כאשר תוקף מערים על אפליקציה מהימנה כך שתשתמש בהרשאות שלה כדי לבצע פעולה שמשתמש לגיטימי לא אישר. במקרה זה, שרת ה-MCP הוא ה"סגן".

התוקף ינצל פגיעות בשרת MCP (כמו אימותי OAuth חלשים) כדי להריץ תהליך זדוני, כמו קריאה לכלי או אחזור נתונים.

כיצד להתגונן מפני מתקפות סגן מבולבל

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

איום מס' 7: שרתים זדוניים ותלויות שנפרצו

שרתי MCP עלולים להכיל קוד זדוני (הם בעצם תוכנות חיצוניות) או להסתמך על תלויות שנפרצו, כמו ספריות של צד שלישי. זוהי בעיה של שרשרת אספקת התוכנה, ולא בעיה ייחודית ל-MCP.

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

כיצד להתגונן מפני שרתים זדוניים ותלויות שנפרצו

התקינו שרתי MCP רק ממקורות מהימנים שנבדקו. אם אפשר, בדקו את הקוד שלהם, ותמיד בדקו כל תלות חיצונית. ודאו שהשרתים מתעדכנים ומקבלים תיקונים באופן קבוע.

איום מס' 8: זיוף בקשות בצד השרת (SSRF)

זיוף בקשות בצד השרת (SSRF) מתרחש כאשר תוקף מערים על שרת MCP כך שישלח בקשות רשת לכתובות פנימיות שהמשתמש לא התכוון לגשת אליהן.

זה יכול לקרות כאשר שרת MCP חושף כלי שמאחזר מידע מכתובת URL. אם תוקף יכול להשפיע על פרמטר ה-URL, הוא יכול לשנות אותו לכתובת הרשת הרצויה לו, כמו API פנימי או שירות ענן. התוצאה עלולה להיות אחזור של נתונים רגישים ואולי אף חשיפתם

כיצד להתגונן מפני זיוף בקשות בצד השרת (SSRF)

שרתי MCP צריכים תמיד לתקף כתובות URL, לחסום גישה לכתובות רשת פנימיות מוגבלות ולמנוע גישה יוצאת לרשת. גם הפניות מחדש (redirects) צריכות לפעול לפי פרוטוקול זה.

איום מס' 9: חטיפת סשן

בחטיפת סשן, תוקף משתלט על חיבור פעיל בין לקוח MCP לשרת.

לדוגמה, התוקף עשוי לגנוב מזהה סשן מאפליקציית MCP שאינה מאובטחת כראוי (למשל, מארח או שרת). אם שרת ה-MCP מקבל את המזהה הזה, התוקף עשוי להיות מסוגל לקרוא לכלים עם ההרשאות הלגיטימיות של המשתמש.

כיצד להתגונן מפני

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

איום מס' 10: מתקפות בלבול (mix-up)

במתקפת בלבול (mix-up), התוקף מערים על לקוח MCP כך שישלח קוד הרשאה לשרת הרשאות זדוני שממוקם בין הלקוח לשרת ה-MCP. שרת הרשאות הוא אפליקציה שמנפיקה טוקני גישה של OAuth לאחר שהיא בודקת שהגישה המבוקשת מורשית.

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

כיצד להתגונן מפני מתקפות בלבול

לקוחות MCP צריכים לאמת את זהות שרת ההרשאות לאורך כל תהליך ה-OAuth. באופן ספציפי, עליהם להשוות את מזהה המנפיק (iss) של השרת לזהות הצפויה ולדחות אי-התאמות.

איום מס' 11: פריצה לשרת MCP מקומי

שרתי MCP רבים פועלים במחשב המקומי של המשתמש. המשתמש עשוי להתקין את השרת מצד שלישי או לבנות אותו בעצמו. אם תוקף מצליח לפרוץ לשרת MCP מקומי זה, הוא עשוי להשיג גישה לחלקים נרחבים של המערכת המקומית.

יש דרכים שונות שבהן תוקף עשוי להשיג גישה. הוא עשוי להפיץ שרת זדוני שמוסווה כשילוב לגיטימי, לשנות את התצורה של מארח MCP כך שינפיק פקודה זדונית, או לגשת לשרת MCP שפועל בסביבה עם בקרות אבטחה לא מספקות, למשל באמצעות DNS rebinding, שמערים על דפדפן כך שישלח בקשות לשירות localhost.

כיצד להתגונן מפני פריצה לשרת MCP מקומי

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

פגיעויות MCP הן לעיתים קרובות איומים ישנים בלבוש חדש

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

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