מה זו התקפת רידיירקט ואיך אתם יכולים להתמגן בפניה

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

אז מה זו התקפת רידיירקט? מדובר בהתקפה פשוטה ביותר שבמסגרתה התוקף משתמש בבאג באתר שמאפשר לו לבצע הפניה לאתר. למשל, בואו ונדמיין שיש לי אתר עיריה שבו יש קישורים לתתי אתרים. בגלל סיבות שונות (כמו למשל תיעוד) יוצרים מנגנון שבו הקישור הוא בעצם לאתר העיריה. בואו ונדגים באמצעות העיר הכי טובה בעולם: פתח תקווה. נניח ויש לי משהו בסגנון הזה:
http://www.petah-tikva.muni.il?target=ahla-bahla.site.com

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

<?php

if($_GET['target']) {
    header('Location: '.$_GET['target']);
}

וב-node.js\express זה יראה ככה:

app.get('/', function(req, res) {
  const target = req.query.target;
  res.status(301).redirect('target');
});

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

בואו נדמיין שאני ספאמר ואני שולח סמס בסגנון הזה:

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

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

התוקפים השתמשו באתר תמים בשם wunderstrauss.de וגילו שם תת אתר הפגיע למתקפה. יש שם רידיירקט שמבצע הפניה לכתובת שנמצאת במסד הנתונים. כלומר הסקריפט הולך למסד הנתונים וקורא ממנו את הכתובת לפי מפתח.
http://tiere.wunderstrauss.de//sender.php?token=1&cae89fc601a7d3bb449a40e0e4802078=bb376f862a9c320e3738d1602cc8633d&id=1
כאן הוא פשוט ניגש אל הפרמטר cae89fc601a7d3bb449a40e0e4802078 ומבקש את המפתח bb376f862a9c320e3738d1602cc8633d שמחזיר לו כתובת. נשמע הכי מאובטח שיש, נכון? במיוחד כאשר המפתח לא התעצל והצפין גם את הפרמטר token=1 ב-MD5 (יד-פרצוף) וה-URL של המשתמש נראה ככה:
http://tiere.wunderstrauss.de//sender.php?94a08da1fecbb6e8b46990538c7b50b2=c4ca4238a0b923820dcc509a6f75849b&cae89fc601a7d3bb449a40e0e4802078=bb376f862a9c320e3738d1602cc8633d&id=1
אבל אם לפורצים יש גישה למסד הנתונים – אז הם יכולים לעשות כל מה שהם רוצים. גישה למסד הנתונים לא אומרת שמישהו פרץ. אם למשל כל משתמש יכול ליצור רידיירקט משלו, אז התוקף, לאחר רישום לאתר, יכול ליצור הפניה משלו בקלות ובלי אפילו להבין את המנגנון מאחורי זה.

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

האתר עצמו ביצע הפניה כל כך מהר שהמשתמש הרגיל לא הבחין בכך.

הפתרון

מה הפתרון? ראשית להמנע מ-redirect לאתרים חיצוניים בכל מחיר. כלומר אך ורק נתיבים ולא קישורים שמתחילים ב-*http.
אם חייבים להשתמש ברידיידרקט לאתר חיצוני? להשתמש ב-white list (כלומר רק רשימה מותרת של אתרים). למשל, משהו בסגנון הזה:

<?php

$sitesArray = ['https://onesite.com', 'https://secondsite.com'];

if($_GET['target']) {
	$target = $sitesArray[$_GET['target']];
    header('Location: '.$target);
}

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

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