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

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

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

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

אבל לא ביקורתי לא אומר לא מזיק. הם יכולים גם לגרום לנזק חמור.

נקודות תורפה "לא קריטיות" מובילות

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

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

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

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

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

אתה יכול לזהות תוכן מעורב באתר באמצעות דפדפן: חפש בקוד המקור של הדף, קרא הודעות במסוף המפתחים. עם זאת, המפתח יצטרך להתעסק עם הקוד במשך זמן רב ומייגע. אתה יכול להאיץ את התהליך עם כלי ניתוח אוטומטיים, למשל: בדוק SSL, תוכנת Lighthouse בחינם או תוכנה בתשלום Screaming Frog SEO Spider.

כמו כן, הפגיעות עלולה להתעורר עקב בעיות עם קוד legacy - קוד שעבר בירושה. לדוגמה, אם חלק מהדפים נוצרים באמצעות תבנית ישנה, שאינה לוקחת בחשבון את המעבר של אתרים ל-https.
קובצי Cookie ללא הדגלים "HTTPOnly" ו-"Secure".
התכונה "HTTPOnly" מגנה על קובצי Cookie מפני עיבוד של סקריפטים שתוקפים משתמשים בהם כדי לגנוב נתוני משתמשים. הדגל "מאובטח" אינו מאפשר שליחת עוגיות בטקסט ברור. תקשורת תתאפשר רק אם נעשה שימוש בפרוטוקול HTTPS המאובטח לשליחת עוגיות.

שתי התכונות מצוינות במאפייני קובצי ה-cookie:
```
Set-Cookie: Secure; HttpOnly
```
מסוכן: אם מפתח האתר לא ציין את התכונות הללו, תוקף יכול ליירט את המידע של המשתמש מהעוגייה ולנצל אותו. אם נעשה שימוש בקובצי Cookie לצורך אימות והרשאה, הוא יוכל לחטוף את ההפעלה של המשתמש ולבצע פעולות באתר בשמו.

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

במקרה זה, התכונה "HTTPOnly" תהפוך את העוגיות לבלתי נראות ל-JavaScript שלך.
פגיעויות מבוססות נתיב.
הסורק מדווח על פגיעות כזו אם הוא מוצא קובץ נגיש לציבור או ספריית אתר עם מידע שעלול להיות סודי. לדוגמה, הוא מזהה קבצי תצורת מערכת בודדים או גישה לכל מערכת הקבצים. מצב זה אפשרי אם זכויות הגישה מוגדרות בצורה שגויה באתר.

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

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

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

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

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

עבור רוב הדפדפנים, אתה יכול להשבית השלמה אוטומטית עם התכונה autocompete="off", לדוגמה:
```
 <body>
    <form action="/iw/form/submit" method="get" autocomplete="off">
      <div>
        <input type="text" placeholder="First Name">
      </div>
      <div>
        <input type="text" id="lname" placeholder="Last Name" autocomplete="on">
      </div>
      <div>
        <input type="number" placeholder="Credit card number">
      </div>
      <input type="submit">
    </form>
  </body>
```
אבל זה לא יעבוד עבור Chrome. זה עוקף באמצעות JavaScript, ניתן למצוא גרסה של המתכון כאן.
הכותרת X-Frame-Options אינה מוגדרת בקוד האתר.
כותרת זו משפיעה על תגי מסגרת, iframe, embed או אובייקט. בעזרתו, אתה יכול לאסור לחלוטין את הטבעת האתר שלך בתוך מסגרת. לשם כך, עליך לציין את הערך X-Frame-Options: deny. או שאתה יכול לציין X-Frame-Options: sameorigin, ואז הטמעה ב-iframe תהיה זמינה רק בדומיין שלך.

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

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

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

ערכי ההכחשה והמקור הזהה של הכותרת X-Frame-Options יפריעו לפעולה של מציג האינטרנט של Yandex. כדי לאפשר שימוש ב-iframes עבור מציג האינטרנט, עליך לכתוב כלל נפרד בהגדרות. לדוגמה, עבור nginx אתה יכול להגדיר אותו כך:
```
http{
...
 map $http_referer $frame_options {
 "~webvisor.com" "ALLOW-FROM http://webvisor.com";
 default "SAMEORIGIN";
 }
 add_header X-Frame-Options $frame_options;
...
}
```
פגיעויות PRSSI (ייבוא גיליון סגנונות ביחס לנתיב).
זוהי נקודת תורפה בסטיילינג של האתר. זה מתרחש אם משתמשים בקישורים יחסיים כמו href="/iw/somefolder/styles.css/" כדי לגשת לקבצי סגנון. תוקף ינצל זאת אם ימצא דרך להפנות את המשתמש לדף זדוני. העמוד יכניס קישור יחסי לכתובת ה-URL שלו וידמה קריאת סגנונות. תקבל בקשה כמו badsite.ru/…/somefolder/styles.css/, שיכולה לבצע פעולות זדוניות במסווה של סגנון.

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

מה מפתח אתרים צריך לזכור: הגדר את הכותרת X-Content-Type-Options ל: nosniff. במקרה זה, הדפדפן יבדוק את סוג התוכן של הסגנונות. אם הסוג שונה מטקסט/css, הדפדפן יחסום את הבקשה.

נקודות תורפה קריטיות

עמוד עם שדה סיסמה מועבר מהשרת בערוץ לא מאובטח (טופס HTML המכיל שדות סיסמה מוגש ב-HTTP).
התגובה מהשרת בערוץ לא מוצפן פגיעה להתקפות "איש באמצע". תוקף יכול ליירט תעבורה ולהתקע בין הלקוח לשרת בזמן שהדף עובר מהשרת ללקוח.

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

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

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

מסוכן: ישנם ניצולים עבור פגיעויות ידועות, למשל:

מה מפתח אתרים צריך לזכור: חזור באופן קבוע למחזור: חפש נקודות תורפה ידועות - תקן - בדוק. אם אתה משתמש בספריות מדור קודם בכוונה, למשל כדי לתמוך בדפדפנים ישנים או כדי לחסוך כסף, חפש הזדמנות לתקן פגיעות ידועה.
סקריפטים בין אתרים (XSS).
Cross-Site Scripting (XSS), או סקריפטים בין אתרים, היא התקפה על יישום אינטרנט שגורמת להחדרת תוכנות זדוניות למסד הנתונים. אם Qualys מוצא פגיעות כזו, זה אומר שתוקף פוטנציאלי יכול או כבר הכניס סקריפט js משלו לקוד האתר כדי לבצע פעולות זדוניות.

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

משתקף XSS קל יותר לביצוע מכיוון שניתן להחדיר סקריפט זדוני לבקשת HTTP. האפליקציה תקבל בקשת HTTP, לא תאמת את הנתונים, תארוז אותם ותשלח אותם מיד. אם תוקף מיירט תעבורה ומכניס סקריפט כמו
```
<script>/*+что+то+плохое+*/</script> 
```
אז תישלח בקשה זדונית בשם הלקוח.

דוגמה בולטת ל-XSS: js sniffers המדמים דפים להזנת CVC, תאריך תפוגה של כרטיס וכן הלאה.

מה מפתח אתרים צריך לזכור: בכותרת Content-Security-Policy, השתמש בתכונה script-src כדי לאלץ את דפדפן הלקוח להוריד ולהפעיל רק קוד ממקור מהימן. לדוגמה, script-src 'self' מפרט את כל הסקריפטים מהאתר שלנו בלבד.
השיטה המומלצת היא קוד מוטבע: אפשר רק javascript מוטבע באמצעות הערך לא בטוח-מוטבע. ערך זה מאפשר שימוש ב-js/css מוטבע, אך אינו אוסר על הכללת קבצי js. בשילוב עם script-src 'self' אנו משביתים הפעלת סקריפטים חיצוניים.

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

מסוכן: אם תוקף מזין שאילתת SQL לטופס זה, הוא יכול לקרוס את מסד הנתונים או לחשוף מידע סודי.

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

בצד הלקוח, כתוב אימות שדה באמצעות JavaScript.

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

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

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

המלצות כלליות

אל תמציא את הגלגל מחדש - השתמש במסגרות מוכחות. ככלל, מסגרות פופולריות בטוחות יותר. עבור .NET - ASP.NET MVC ו-ASP.NET Core, עבור Python - Django או Flask, עבור Ruby - Ruby on Rails, עבור PHP - Symfony, Laravel, Yii, עבור JavaScript - Node.JS-Express.js, עבור Java - קפיץ MVC.

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

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

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

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

מקור: www.habr.com

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

נקודות תורפה "לא קריטיות" מובילות

נקודות תורפה קריטיות

המלצות כלליות

הוספת תגובה ביטול תגובה