דרכים לאבטחת שימוש בapi

[אביי]

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

אז כרגע יישמתי את 2 הדברים הבאים:

• בפרודקשן אני חוסם את הבקשות בget כמובן.
• הגישה דורשת מפתח API ייחודי לכל קליינט שצריך להישלח כheader. - חוסם את הגישה למרחבי האינטרנט..

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

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

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

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

[dovid]

ריקאפצ'ה לא טוב?

[nigun]

@אביי כתב בדרכים לאבטחת שימוש בapi:

היינו למנוע ממשתמש להדביק את הכתובת בדפדפן ולקבל את המידע..

לא הבנתי מה אתה מנסה למנוע

בניית בוט שישלוף את המידע?
הדבקה חד פעמית בדפדפן/CURL? מה זה שונה מלראות את אותו מידע בכלי מפתחים בלי לשלוח בקשה מחדש?

[5566brs]

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

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

[צדיק תמים]

@5566brs כתב בדרכים לאבטחת שימוש בapi:

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

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

[5566brs]

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

[אבי]

@צדיק-תמים כתב בדרכים לאבטחת שימוש בapi:

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

@אביי קח את השורה הזו לתשומת לבך. גזור ושמור.
אני מצד העכבר...

[אביי]

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

באנלוגיה של בקשת GET, אני רוצה למנוע ממנו להדביק בדפדפן https://api.site.com/app/addlist?id=132&name=tamar ולהוסיף רשימה חדשה (שאז אפשר לשרשר רשימה משיטס לדוגמה וכן הלאה)..

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

[צדיק תמים]

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

[צדיק תמים]

@אביי כתב בדרכים לאבטחת שימוש בapi:

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

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

[אביי]

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

לא השתמשתי בקאפצ'ה, אני אכן אבדוק את זה בעז"ה.

תודה לכל העונים,

[nigun]

@אביי
אם

אני מיישם בעיקרון את כל המגבלות בשני הצדדים

אז

אני רוצה למנוע ממנו להדביק בדפדפן https://api.site.com/app/addlist?id=132&name=tamar ולהוסיף רשימה חדשה

לא אמור להיות אפשרי
(אמור להיות ספירה בצד שרת כמה הלקוח הוסיף וכדו')

@צדיק-תמים כתב בדרכים לאבטחת שימוש בapi:

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

למה צריך פוסטמן? אפשר לעשות העתק כCRUL ולהדביק בטרמינל בלי להבין מידי הרבה.

[nigun]

@אביי כתב בדרכים לאבטחת שימוש בapi:

באנלוגיה של בקשת GET, אני רוצה למנוע ממנו להדביק בדפדפן https://api.site.com/app/addlist?id=132&name=tamar ולהוסיף רשימה חדשה (שאז אפשר לשרשר רשימה משיטס לדוגמה וכן הלאה)..

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

[כמה טוב השם]

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