פגיעויות מובילות של OATH API

פגיעויות מובילות של OATH API: מבוא

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

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

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

הרשאה ברמת אובייקט שבור

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

אימות משתמש שבור

אסימונים לא מורשים הם דרך נפוצה נוספת לתוקפים להשיג גישה לממשקי API. מערכות אימות עשויות להיפרץ, או מפתח API עלול להיחשף בטעות. יכול להיות אסימוני אימות בשימוש על ידי האקרים לרכוש גישה. אימות אנשים רק אם ניתן לסמוך עליהם, והשתמש בסיסמאות חזקות. עם OAuth, אתה יכול ללכת מעבר למפתחות API בלבד ולקבל גישה לנתונים שלך. אתה תמיד צריך לחשוב איך אתה נכנס ויוצא ממקום. OAuth MTLS Sender Constrained Tokens עשויים לשמש בשילוב עם Mutual TLS כדי להבטיח שלקוחות לא יתנהגו בצורה לא נכונה ויעבירו אסימונים לגורם השגוי בזמן שהם ניגשים למכונות אחרות.

קידום API:

חשיפת נתונים מוגזמת

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

חוסר משאבים והגבלת תעריפים

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

תצורה שגויה של מערכת האבטחה

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

מטלה המונית

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

ממשק API מקודם:

ניהול נכסים לא תקין

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

הזרקה

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

רישום וניטור לא מספיקים

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

סיכום

ארכיטקטי פלטפורמה עשויים לצייד את המערכות שלהם כדי להישאר צעד אחד לפני התוקפים על ידי ביצוע קריטריוני פגיעות שנקבעו. מכיוון שממשקי API עשויים לספק נגישות למידע אישי מזהה (PII), שמירה על האבטחה של שירותים כאלה היא קריטית הן ליציבות החברה והן לעמידה בחקיקה כגון GDPR. לעולם אל תשלח אסימוני OAuth ישירות דרך API מבלי להשתמש ב-API Gateway ובגישה של Phantom Token.