HTTP 407 או 401: איזו כניסה נכשלת?
הבחינו בין אימות מול הפרוקסי לאימות מול האתר, בדקו את הכותרות הנכונות ואל תשלחו פרטי כניסה לצד הלא נכון.
407 מבקש אימות מול הפרוקסי. 401 מבקש אימות למשאב היעד. בקשה יכולה להיתקל בשניהם, לכן בררו מי מבקש לפני מסירת סיסמה.
השוו את הסטטוס ואת כותרות דרישת האימות
| תגובה | כותרת דרישת אימות | כותרת פרטי כניסה | הצד המעורב |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | פרוקסי מתווך |
| 401 Unauthorized | WWW-Authenticate | Authorization | תהליך האימות של משאב המקור |
הסטטוס הוא רמז ראשון חשוב, אבל בדקו את כל חילופי ההודעות. המספר 407 בטקסט של דף אינו תגובת HTTP 407 ממשית. בדומה לכך, דף כניסה מותאם יכול להחזיר 200 ועדיין לדרוש אימות בשכבת היישום.
למה HTTPS עלול להיכשל עם 407 לפני שהגיע לאתר
כשפרוקסי HTTP רגיל מעביר בקשת HTTPS, הלקוח מבקש בדרך כלל תחילה מנהרת CONNECT. הפרוקסי יכול לדרוש אימות לבקשת CONNECT הזאת. אם האימות לא הושלם, הפעלת TLS מול היעד דרך המנהרה עדיין לא הוקמה. לכן החלפת אסימון API של האתר כנראה לא תתקן את השלב הזה.
השתמשו בפלט מפורט כדי לראות היכן מופיעה דרישת האימות:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/החליפו את נקודת ההאזנה המקומית בשלכם וקראו את הדרישה הראשונה ביומן. 407 בזמן CONNECT מופיע לפני TLS מול היעד; 401 מאוחר יותר יכול להופיע אחרי הקמת מנהרה תקינה.
מסרו פרטי כניסה דרך ממשק הפרוקסי
לנקודת קצה וחשבון שסיפק מנהל שאתם סומכים עליו, curl יכול לנהל משא ומתן על שיטת האימות ולבקש סיסמה שלא צוינה:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/החליפו את נקודת הקצה והמשתמש שבדוגמה בפרטי השירות שאתם מורשים להשתמש בו. ציון המשתמש בלבד מונע הצבת סיסמה ישירות בפקודה שלעיל. השיטות הנתמכות משתנות לפי בניית curl והפרוקסי; אם המשא ומתן נכשל, בדקו את דרישת האימות בפועל ואת יכולות הבנייה.
אפשרות האימות לפרוקסי נפרדת מאפשרות המשתמש מול המקור ב־curl. אל תוסיפו כותרת Authorization למקור במקום מענה לדרישת הפרוקסי. הימנעו גם מהעברה ידנית של כותרות פרטי הפרוקסי לבקשות לא קשורות או משמירתן בכותרות שמשמשות את היישום כולו.
אם הפרוקסי ממשיך להחזיר 407
- ודאו שאתם משתמשים במארח ובפורט של הפרוקסי המתוכנן.
- בדקו את שיטות האימות שהפרוקסי מפרסם במקום להניח Basic.
- ודאו את מצב החשבון ואת פורמט המשתמש שהשירות דורש.
- בדקו את העברת התווים המיוחדים אם פרטי הכניסה מוטמעים ב־URL.
- בררו אם אימות ארגוני המשולב בדפדפן צריך תמיכה של סביבת הריצה או הפלטפורמה.
- אם הראיות בצד הלקוח אינן מספיקות, בקשו מהמנהל מזהה בקשה או רשומת יומן שרת שהוסרו מהם פרטים רגישים.
403 או CONNECT שנדחה יכולים להיות החלטת מדיניות גישה גם אחרי כניסה מוצלחת. ניסיונות סיסמה נוספים לא יעניקו גישה ליעד אסור.
HTTPS של היעד אינו מגן על כל חילופי פרטי הכניסה של הפרוקסי
אימות מול הפרוקסי יכול לקרות לפני הקמת TLS מול היעד. אם החיבור לפרוקסי עצמו אינו מוצפן והשיטה חושפת בו פרטי כניסה לשימוש חוזר, יעד HTTPS לא מגן בדיעבד על ההחלפה הזאת. בחרו תעבורה ושיטת אימות שמתאימות לשירות, ואל תשלחו חשבונות פרטיים לפרוקסי ציבורי לא מוכר.
עברו על היומנים המפורטים לפני שיתוף. גם אם הכלי מסתיר שדות כניסה מקובלים, ייתכן שיישארו שמות משתמשים, שמות נקודות קצה פנימיות, עוגיות או מידע מזהה אחר.