פרשת כרטיסי האשראי – הצדדים החיוביים

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

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

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

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

I hacked my Google Account, Yours might be in danger too

Today I suddenly remembered one of my old Google Accounts (created, I assume, in 2007), that I used mostly for Gmail and YouTube. Though I rememberd my Username and password, Google didn't let me in. It said it need to verify I know my previous Log in locations or Security Question. As I said, the account was longly forgotten, back when Location-based services were nothing but a good idea, so I don't think it has any location log. I tried a bunch of guesses, but none of them worked.

So I got my Iphone (3G) and tried to log in to Mail. I Succedded and got to read my mail. I tried to log in to the YouTube app, and succedded as well. I guess Google haven't really thought out Mobile Security. With the details I now know such as contacts and mailing history, I tried recovering my account via this page, and got this email where Google say they take my privacy and security seriously, so they can't grant me the access to the account.

But the best part came when I got to my iPhone's Safari and tried to access my account: I got the same page asking for my "Previous Locations or Security Question". "I just logged In via Mail and YouTube apps" I thought, "will this log my location?". Yes, It did, I typed my current location (one of the previous guesses I mentioned) and It validated my account and I got to use my old account.

Great. I got back my account, and All is well. But wait, what if I WERE a hacker? if someone got my username and password and tried to log in from somewhere around the globe and got that message saying "Is that really you?" all the hacker needed to do is log in to some apps in his old iPhone and recieve my account information and details? disturbing.

היום בו ניצחתי את גוגל, והשגתי בחזרה את חשבון ה-Gmail שלי. או: פרצת אבטחה ב-Google Accounts.

היום נזכרתי, משום מה, באחד מחשבונות ה-Google שלי: אחד עתיק במיוחד (ככל הנראה מ-2007), ששימש אותי לתקופה קצרה, בעיקר ל-YouTube ו-Gmail. כשניסיתי להתחבר אליו (זכרתי את הסיסמא ושם המשתמש), YouTube הפצירה בי להיכנס עם ה-Google Accounts, כיוון שהם לא תומכים יותר בחשבונות YouTube בלבד. ה-Google Accounts הם חשבונות שמשמשים את כלל השירותים של גוגל, ומטבע הדברים הם מאובטחים הרבה יותר מחשבונות YouTube עתיקים, כך שזה הגיוני לחלוטין ש-YouTube יפסיקו לתמוך בהם. אז ניסיתי להתחבר לחשבון ה-Google Accounts שלי, ושם כבר הייתה בעיה…

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

תחי מהפכת הסלולר

אז ניסיתי להתחבר למייל דרך ה-iPhone שלי. ה-iPhone 3G שלי אף פעם לא אכזב אותי, והוא לא מאכזב אותי גם הפעם: לאפליקציית המייל אין אותנתיקציה עם Google Accounts, שכבר בטוחים שאני מנסה לפרוץ לעצמי לחשבון ומערימים עליי קשיים, ואכן, הצלחתי להתחבר ולקרוא את המיילים הישנים דרך האייפון (לא היה שם שום דבר מעניין, אם זה מעניין מישהו) ללא כל קושי.

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

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

האם חשבונות גוגל מאובטחים?

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

איך לשפר את הטפסים באתר כבר היום עם HTML5

רצף המילים HTML5 מתרוצץ באינטרנט כבר כמה שנים טובות. הבטיחו לנו Canvas! וידאו! אודיו! ואף שאפשר להסכים או לא להסכים על הפונקציונליות של השפה הזו, יש חלקים שבהם HTML5 עושה חסד גדול עם מפתחי האתרים. אחד מהם, הוא השימוש בטפסים. בעבר, היינו פותחים טופס עם <form>, זורקים בו כמה input type="text" ומסימיים עם input type="submit" וסיימנו. היום, בעזרת החידושים של HTML5 אנו יכולים לשפר את הטפסים באתר שלנו פלאים – לדוגמא מבחינת נוחיות המשתמש ותמיכה במשתמשים עם מוגבלויות ואפילו מבחינת הפונקציונליות במכשירים ניידים.

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

על מה אני מדבר? 

  • Placeholder
    התג הנהדר הזה מאפשר לנו לציין טקסט אפור שיופיע בתוך ה-Input כל עוד הוא לא בפוקוס ואין בו טקסט (הערך של תא Input שלא הכנסנו אליו את הסמן וכתבנו בו יהיה כלום – ""). ברגע שה-Input ייכנס לפוקוס הטקסט יעלם כלא היה ונוכל להכניס אליו את הערך שנרצה. אין לי מילים לתאר כמה שורות קוד Javascript התג הזה חוסך!
<input type="search" placeholder="Your Text Here">
  • Autofocus
    גם התג הזה חוסך לנו אינספור שורות קוד. הרי מי לא התלבט מתי לשים את הפוקוס, כשהמסמך סיים לטעון את התמונות שבו (window.onload) ? רק את הטקסט? document.ready? ומי מאיתנו, ה-Power Users לא התחרפן כשהפוקוס נעלם מהשדה בו כתבנו בטופס לתא אחר? Autofocus מאפשר לנו לעשות Focus ברגע שהדף נטען, מבלי לכתוב שורת Javascript אחת!
    כמובן, שבמידה והפרויקט דורש תמיכה לאחור – יש לציין focus. וכמובן ש-Jquery מאפשר לעשות זאת בקלות, כך:
 document.getElementById("imput-id").focus(); 
  • תגי Input
    תג ה-Input שופר פלאים. נוספו המון Typeים חדשים, כאלו שמציעים פונקציונליות מהפכנית (במיוחד למשתמשי המובייל והטאבלטים) ושימושיות עדכנית לטפסים.
  1. לדוגמא, Input type="search" מייצר תיבת טקסט רגילה לחלוטין, רק עם הבדל אחד: בתוך תיבת הטקסט  יווצר כפתור קטן למחיקה של הטקסט שהוקלד, ברגע שהוקלד. דוגמא ניתן למצוא בתיבת החיפוש באתר Apple.
  2. דוגמא נוספת, היא type="date", (או month/year וכו'…) שמוסיף כפתורים לניהול התאריך שהוכנס בתוך תיבת הטקסט.
  3. דוגמא לפונקציונליות משופרת היא דווקא input type="email" שגורמת למשתמשי ה-Iphone לקבל מסך מקלדת מגע מותאמת בדיוק להקלדת e-mail: כלומר, מכילה אך ורק את התווים המותרים, כמו האותיות a-Z וכפתור מיוחד לתו ה-@.
  4. דוגמאות נוספו לתג זה הן input type="url", input type="number", input type="color" וכו'.
  • Ranged Input
    חידוש משמעותי הוא Input type="range" שמעתה מאפשר ליצור טווח עליו ניתן לגרור את הסמן כדי לבחור ערך (מוכר מאוד למשתמשי ה-Iphone והטלפונים הניידים, פתרון דומה ניתן בעזרת jQuery UI שכיום כבר לא רלוונטי!).
נחמד לדעת: ניתן להגדיר שדות בתור "חובה למילוי" על ידי הוספה של המילה required.
נחמד לדעת: ברגע שמשתמשים באפשרויות אלו, HTML גם ייבדוק האם האימייל שהוכנס תקני, האם ניתן להכניס את התאריך שהוכנס, האם כל השדות שהוגדרו כחובה הוכנסו וכו'. במידה ונרצה לדלג על הבדיקה משום מה, נכניס בתג ה-FORM את המילה novalidate.
חשוב לציין, שמכיוון שניתן ליצור תיבת טקסט גם כאשר type="text" הושמט, כל הסוגים החדשים של HTML5 נופלים לאחור לתיבת טקסט רגילה לחלוטין, במידה והדפדפן אינו תומך ב-HTML5. לכן הוספה של אפשרויות אלו לתג ה-Input בטפסים של אתרך מאפשרת את כל הפונקציונליות הזו, בלי להפסיד שום דבר! במידה והדפדפן של המשתמש אינו תומך ב-HTML5, הדפדפן ירנדר את התיבה כתיבת טקסט, והרי זו התוצאה גם היום!
אני רוצה לראות אתכם משתמשים בזה כבר היום!

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

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

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

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

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

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

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

אבטחת Cookies (עוגיות) ו-Sessions (סשנים) בPHP

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

עוגיות, סשנים ומה שבינם

 

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

בפוסט זה אתייחס לנושאים באבטחה בסיסית עד בינונית שניתן להשיג באתרים מבוססי 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 – הזרקת קוד (חלק 2)

אמשיך בסדרת המאמרים על הזרקות קוד (כהמשך לחלק הראשון), ואזכיר שראשי התיבות 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 – מכיל בתוכו הצבעה לפקודה הבאה שצריכה להתבצע) ולשם להכניס קטע קוד שייתן לנו הרשאות בצורה מסודרת.