שיטות HTTP: CONNECT ו-TRACE

בעוד ש-GET, POST, PUT ו-DELETE מטפלים ברוב תעבורת האינטרנט, HTTP כולל שתי שיטות מיוחדות למקרי קצה: CONNECT למעבר מנהרה דרך פרוקסי, ו-TRACE לאקו אבחוני. האחת היא תשתית חיונית. השנייה היא סיכון אבטחה שכמעט כבר כיבינו.

CONNECT: להפוך את הפרוקסי לשקוף

CONNECT קיים מפני ש-HTTP לא תוכנן לחיבורים מוצפנים דרך מתווכים.

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

CONNECT פותר זאת על ידי הפיכת הפרוקסי לצינור סביל:

CONNECT bank.com:443 HTTP/1.1
Host: bank.com:443

זה אומר לפרוקסי: "פתח חיבור TCP ל-bank.com על פורט 443. ואז הפסק להיות פרוקסי HTTP. פשוט העבר בתים בשני הכיוונים מבלי להסתכל בהם."

הפרוקסי מגיב:

HTTP/1.1 200 Connection Established

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

מה שהופך את CONNECT לחריג

בקשות CONNECT נראות שונות מ-HTTP רגיל:

CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==

ה-URI אינו נתיב — הוא יעד מסוג מארח:פורט. ו-Proxy-Authorization מאמת מול הפרוקסי, לא מול שרת היעד.

מדוע פרוקסי מגבילים את CONNECT

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

רוב הפרוקסי מגנים על עצמם:

הגבלות פורט: מאפשרים CONNECT רק לפורט 443 (HTTPS). בקשה לפורט 22 (SSH) נדחית:

CONNECT server.com:22 HTTP/1.1
→
HTTP/1.1 403 Forbidden

אימות נדרש: אין מנהרה אנונימית.

רשימה לבנה של דומיינים: חלק מהפרוקסי הארגוניים מנהרים רק ליעדים מאושרים.

תיעוד: פרוקסי לא יכולים לראות את תוכן המנהרה, אך הם מתעדים מי מתנהר לאן.

CONNECT קורה אוטומטית

אתה כמעט אף פעם לא רואה את CONNECT ישירות. כשהדפדפן שלך מוגדר עם פרוקסי HTTP, הוא שולח CONNECT אוטומטית עבור אתרי HTTPS:

הדפדפן מבקר ב-https://secure-site.com
↓
דפדפן → פרוקסי: CONNECT secure-site.com:443
פרוקסי → דפדפן: 200 Connection Established
דפדפן ↔ פרוקסי ↔ אתר: תעבורה מוצפנת זורמת דרך המנהרה

חיבורי WebSocket דרך פרוקסי עובדים באותה דרך — CONNECT יוצר את המנהרה, ואז שדרוג ה-WebSocket מתרחש בתוכה.

בניית תמיכת CONNECT

אם אתה מממש פרוקסי:

server.on('connect', (req, clientSocket, head) => {
  const { port, hostname } = new URL(`http://${req.url}`);
  
  // אבטחה: מאפשרים רק פורט HTTPS
  if (port !== '443') {
    clientSocket.write('HTTP/1.1 403 Forbidden\r\n\r\n');
    clientSocket.end();
    return;
  }
  
  const serverSocket = net.connect(port, hostname, () => {
    clientSocket.write('HTTP/1.1 200 Connection Established\r\n\r\n');
    serverSocket.pipe(clientSocket);
    clientSocket.pipe(serverSocket);
  });
  
  serverSocket.on('error', () => {
    clientSocket.write('HTTP/1.1 502 Bad Gateway\r\n\r\n');
    clientSocket.end();
  });
});

TRACE: כשהשקיפות הפכה לנשק

TRACE תוכנן לאיתור תקלות. שלח בקשה, והשרת מחזיר כהד בדיוק מה שקיבל:

TRACE /path HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0

השרת מגיב:

HTTP/1.1 200 OK
Content-Type: message/http

TRACE /path HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
X-Forwarded-For: 192.168.1.100
Via: 1.1 proxy.example.com

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

בעיית האבטחה

השקיפות של TRACE הפכה לחולשת אבטחה בשם Cross-Site Tracing (XST).

דפדפנים מגנים על עוגיות עם דגל HttpOnly — JavaScript לא יכול לקרוא אותן. אך TRACE מחזיר כהד הכל בגוף התגובה, כולל עוגיות וכותרות הרשאה:

// הסקריפט של התוקף
fetch('https://victim-site.com/', { method: 'TRACE' })
  .then(r => r.text())
  .then(body => {
    // הגוף מכיל:
    // Cookie: session=secret-session-id
    // Authorization: Bearer secret-token
  });

העוגיות הן HttpOnly, אז הסקריפט לא יכול לקרוא את document.cookie. אך TRACE מחזיר אותן כטקסט רגיל, עוקף את ההגנה לחלוטין.

TRACE כמעט מת

בשל XST, TRACE מושבת כברירת מחדל על כמעט כל השרתים המודרניים:

• Apache: TraceEnable Off
• Nginx: לא תומך ב-TRACE כלל
• IIS: מסונן כברירת מחדל

רוב השרתים מחזירים 405 Method Not Allowed. סורקי אבטחה מסמנים TRACE מופעל כחולשת אבטחה.

כותרת Max-Forwards

TRACE תומך ב-Max-Forwards למעקב דרך שרשרות פרוקסי:

TRACE / HTTP/1.1
Max-Forwards: 2

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

בפועל, אף אחד לא משתמש בזה כי TRACE עצמו מושבת בכל מקום.

גורלות שונים

CONNECT נשאר חיוני. כל חיבור HTTPS דרך פרוקסי משתמש בו. אתה לא רואה אותו, אבל הוא שם — התשתית הבלתי נראית שמאפשרת גלישה מוצפנת ברשתות ארגוניות.

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

app.all('/debug/echo', (req, res) => {
  res.json({
    method: req.method,
    headers: req.headers,
    ip: req.ip
  });
});

אותה יכולת ניפוי שגיאות, ללא חור אבטחה.

שאלות נפוצות על HTTP CONNECT ו-TRACE

מדוע פרוקסי לא יכולים פשוט להעביר בקשות HTTPS רגיל?

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

האם אני צריך לממש CONNECT באפליקציית האינטרנט שלי?

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

האם TRACE חסר תועלת לחלוטין עכשיו?

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

כיצד אני בודק אם TRACE מושבת בשרת שלי?

curl -X TRACE https://your-server.com/

אתה אמור לקבל 405 Method Not Allowed. אם אתה מקבל 200 עם הבקשה שלך כהד חזרה, השבת את TRACE מיד.