אבטחת מידע בוורדפרס

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

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

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

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

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

שיטת הפריצה הראשונה – XSS

מדובר באחת השיטות האהובות והמוכרות ביותר. ראשי התיבות שלה היא Cross Site Scripting ובגדול היא מתבססת על היכולת של הפורץ לשתול ג'אווהסקריפט בתוך האתר. איך שותלים ג'אווה סקריפט בתוך האתר? יש שלל שיטות שונות. בואו ונפעיל את הדמיון ונראה – נניח ויצרתי תוסף או שאני משתמש בתוסף שהמטרה שלו היא לשלוח מסר מהמשתמש אל מנהל האתר בלבד. בתחתית כל פוסט יש שדה טקסט וכפתור submit שלוקחת את הטקסט ומציגה אותו בדף ב-admin.

פשוט, לא? אבל הפירצה כאן היא כזו – התוקף יכול להכניס JavaScript לאתר. למשל משהו כזה

טוב, מה הבעיה הגדולה כאן? אז אני יכול לשגע קצת את המנהל עם alert. אבל נזק ממשי לא יכול לקרות כאן, לא? התשובה כאן היא: בוודאי שכן. ברגע שיש לי יכולת להריץ JS על הדף, אז יש לי יכולת לעשות כל דבר. לגנוב sessions, לעשות פעולות בשמו של המנהל, להאזין למקלדת שלו ובעצם לעשות כל דבר. בגלל זה רוב הדגמות ה-XSS נעשות עם alert. כי אם אני יכול להקפיץ alert אני יכול לעשות כל דבר שמתחשק לי באתר וזו בעצם הפירצה ומדובר באחת הפרצות הידועות והשימושיות ביותר.

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

אם אתם מקבלים מידע מהמשתמש, יש לבצע בו ולידציה בצד השרת. מה זאת אומרת? לוודא שהוא מכיל את מה שהוא אמור להכיל. אם זה URL, שיכיל URL. אם זה טקסט פשוט, אז שלא יהיו בו תגיות HTML או JS. וורדפרס מספקת לנו שפע של פונקציות לעשות את זה בלי לשבור את הראש. אתם מקבלים מידע מהמשתמש? אז חייבים להעביר כל אינפוט דרך ה-data validation.

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

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

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

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

You came from $_SERVER['HTTP_REFERER'], but you got 404

מדובר בפירצה. למה? אני יכול להכניס ל-URL משהו כזה:

wordpress.com/<script>alert(1)</jscript>

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

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

You came from echo esc_url( $_SERVER['HTTP_REFERER'] ), but you got 404

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

<video onerror="alert(1)"><source></source></video>

הקוד הזה מריץ JS בכל דפדפני אקספלורר, גם החדשים. כלומר כל מי שיכנס לאתר שלכם עם אקספלורר – יהיה אפשר להריץ JS בדפדפן שלו ולעשות כל מיני דברים. כלומר גם אם וידאתי שאין script או javascript: יצליחו להכניס לי XSS ויש עוד המון פרצות כאלו ולא רק לאקספלורר. ריכוז של פרצות כאלו נמצא באתר HTML5Sec.

אז איך מתגוננים?

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

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

esc_html
esc_textarea
esc_url
urlencode
is_email
sanitize_email()     
sanitize_file_name()     
sanitize_html_class()     

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

CSRF

פירצה שניה שאני ממש אוהב נקראת CSRF או יותר נכון Cross Site Request Forgery.

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

<a href=”wordpress.com/wp-admin/myuser?uid=1&op=delete”><img src=”See_bar_naked.png” /></a>

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

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

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

בקודקס של וורדפרס מסבירים היטב על nonce.

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

אם אתם משתמשים, חפשו בתוסף שלכם את המילים nonce או check_admin_referer(), check_ajax_referer(), wp_referer_field() . ברגע שמצאתם אותן אתם יכולים להיות בטוחים שיש כאן מודעות לנושא ה-token. במידה ולא – זה לא אומר שהמתכנתים התרשלו, אבל זה אומר שמתכנת מנוסה צריך לבדוק את התוסף. אגב, גם פה על הבדיקה הזו אפשר וצריך לגבות כסף.

SQL Injection

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

בואו ונניח שיש לי דף בתבנית שמציג את פרופיל המשתמש:

$account_id = $ _GET[‘uid’];
$myrows =
$wpdb->get_results("SELECT * FROM users WHERE uid = $account_id”);
//Display users

המשתמש הזדוני יכול להכניס ל-URL משהו כזה:

wordpress.com/user_profile/?uid=”1'; DROP TABLE users; –'/”

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

יש כמה פתרונות לפירצה הזו. הראשונה, שטובה גם ל-XSS, היא לעשות ולידציה וסניטציה לכל מה שמגיע מהמשתמש. כלומר אין מצב שאני אקח משתנה $_GET ואשתמש בו בכלל בלי לבדוק מה הוא, מי הוא ולנקות אותו.
הפתרון השני הוא לא להכניס ישירות נתונים לשאילתה אלא להשתמש ב-sprintf או במקרה של וורדפרס ב-$wpdb->prepare שמכניס את הנתונים באופן תקין אל השאילתה ומונע SQL Injection. אם אתם מתכנתים וצריכים לבצע שאילתה ישירות אל מסד הנתונים, שווה לקרוא את wpdb ואת התיעוד לפונקציה הזו.

אם אתם משתמשים, תבדקו בקוד של התוסף אם יש $wpdb – אם אין, סביר להניח שאין שאילתות ישירות אל מסד הנתונים. אם מדובר בתוספים פשוטים ולא ב-CF7 או דברים כאלו, ב-99% אין שום סיבה לשימוש בשאילתה ישירה אל מסד הנתונים ואין שום סיבה שיהיה בכלל $wpdb. אם יש, זה אומר דרשני ויש לנתח את הקוד. מדובר בבדיקה שצריך וכדאי לקחת עליה כסף.

החדרת קוד זדוני אל תוספים באמצעות "הצפנה"

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

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

//Before:
<?php
Print "Hello world!";
//After:
<?php 
Printbase64_decode('SGVsbG8gd29ybGQh');

//Using http://www.gaijin.at/en/olsphpobfuscator.php 

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

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