הבטחה לאבטחה - eCommerce
אבטחת מידע באתרי מכירה אונליין הינם נושא שעומד על הפרק מזה מספר שנים. למעשה עוד מימי
אתר המסחר הראשון שעבד בשיטת המכרזים ( צינזרתי את שמו ) ונסגר בשלב מסויים בעיקר בשל הפחד של הגולשים לרכוש דרכו. מאז ומעולם הטבע האנושי אינו מאמין בקניין רוחני ( פרט אולי לאנשי המדע והאומנות ) ועוד יותר איננו מאמינים במסירת פרטי האשראי שלנו בצורה מקוונת , בטח ובטח אחרי כלכך הרבה סרטים בנושא, וכתבות מהסוג הזה :-).
נושא זה היווה בעייה כלל עולמית במסחר אלקטרוני ( eCommerce ) ולכן הדרך שנראתה הכי נכונה לטפל בנושא הייתה באמצעות אלמנטים של הצפנה. היום לא תראו אתר מסחר אחד שמכבד את עצמו , שלא יפרסם ( בתקנון או בתמונה בעמוד הראשי ) שהוא מצפין את החלפת הפרטים בSSL , ושהמידע מעורבל. חלק מחברות המסחר אף טרחו להסביר שמסדי הנתונים מופרדים מאחורי הקלעים באמצעות Firewalls ביניהם ולכן אפילו יותר מוגנים.
אז ראשית קצת טכני, SSL הוא אכן פרוטוקול הצפנה יעיל. הוא מאפשר החלפת מפתחות בין שני
צדדים שהם Client\Server ועל ידי יצירת Session וירטואלי ( מאחר ובHTTP1.0 או ב1.1 לא קיים אלמנט הSESSION ) לערבל ולהצפין את המידע העובר בין הCLIENT לSERVER ולהיפך, ועל ידי כך למעשה ליצור טרנזאקציה בטוחה.
התצורה :
אז נכון שאתרי המסחר כולם עברו לעבוד בשיטת הSSL , ואכן מצפינים את שלב החלפת פרטי האשראי , תעודת הזהות וכמובן פרטים כמו תוקף הכרטיס וכתובת המשלוח... שכן אלו הפרטים הרגישים ביותר לנו. האומנם ?
הבעיה היא ...
95% מהאתרים בארץ ובעולם אשר מבצעים טרנזאקציות של מידע שמור ואישי , כולל אתרי מסחר אלקטרוני , בנקים , שירותים פרטיים וכדומה , אינם מצפינים את החלפת שם המשתמש והסיסמה.
מה שנוצר בתהליך זה הוא שלמרות שאת המידע הרגיש שלי אי אפשר לגנוב On-The-Fly על ידי
Sniffing או Hijacking ( יש לי סייגים פה ) אבל ניתן לגנוב את שם המשתמש והסיסמה שלי שמשודרים PLAINTEXT עוד לפני שהעברתי פרט אחד !!! אם לאותו CRACKER יש את השם משתמש והסיסמה שלי , הוא לא צריך לחפש את האשראי שלי , כי הפרטים כבר מולו !!!.
אתם מוזמנים לנסות בעצמכם , גשו לאתר המכירות האהוב עליהם , פנו לפריט מסויים שאתם רוצים לרכוש וחפשו את שדות המשתמש והסיסמה בעמוד. הם שם ? יפה ... והאם אתם רואים את המנעול הקטן של הSSL למטה ? לא ? מעניין ...
ישנם גופים אשר מתעוררים לבעיה זו , ועל סמך כך אנו יכולים לראות יותר ויותר אתרים שמקשים על ההזדהות , שמעבירים דרך כמה מסכי הזדהות , וחלקם אף הגיעו למצב המבוקש , בו לא ניתן להזין שם משתמש או סיסמה בעמוד שאינו SSL Encrypted.
אשמח לשמוע הצעות או רעיונות בנושא זה, אתם מוזמנים לכתוב.
אתר המסחר הראשון שעבד בשיטת המכרזים ( צינזרתי את שמו ) ונסגר בשלב מסויים בעיקר בשל הפחד של הגולשים לרכוש דרכו. מאז ומעולם הטבע האנושי אינו מאמין בקניין רוחני ( פרט אולי לאנשי המדע והאומנות ) ועוד יותר איננו מאמינים במסירת פרטי האשראי שלנו בצורה מקוונת , בטח ובטח אחרי כלכך הרבה סרטים בנושא, וכתבות מהסוג הזה :-).
נושא זה היווה בעייה כלל עולמית במסחר אלקטרוני ( eCommerce ) ולכן הדרך שנראתה הכי נכונה לטפל בנושא הייתה באמצעות אלמנטים של הצפנה. היום לא תראו אתר מסחר אחד שמכבד את עצמו , שלא יפרסם ( בתקנון או בתמונה בעמוד הראשי ) שהוא מצפין את החלפת הפרטים בSSL , ושהמידע מעורבל. חלק מחברות המסחר אף טרחו להסביר שמסדי הנתונים מופרדים מאחורי הקלעים באמצעות Firewalls ביניהם ולכן אפילו יותר מוגנים.
אז ראשית קצת טכני, SSL הוא אכן פרוטוקול הצפנה יעיל. הוא מאפשר החלפת מפתחות בין שני
צדדים שהם Client\Server ועל ידי יצירת Session וירטואלי ( מאחר ובHTTP1.0 או ב1.1 לא קיים אלמנט הSESSION ) לערבל ולהצפין את המידע העובר בין הCLIENT לSERVER ולהיפך, ועל ידי כך למעשה ליצור טרנזאקציה בטוחה.
התצורה :
אז נכון שאתרי המסחר כולם עברו לעבוד בשיטת הSSL , ואכן מצפינים את שלב החלפת פרטי האשראי , תעודת הזהות וכמובן פרטים כמו תוקף הכרטיס וכתובת המשלוח... שכן אלו הפרטים הרגישים ביותר לנו. האומנם ?
הבעיה היא ...
95% מהאתרים בארץ ובעולם אשר מבצעים טרנזאקציות של מידע שמור ואישי , כולל אתרי מסחר אלקטרוני , בנקים , שירותים פרטיים וכדומה , אינם מצפינים את החלפת שם המשתמש והסיסמה.
מה שנוצר בתהליך זה הוא שלמרות שאת המידע הרגיש שלי אי אפשר לגנוב On-The-Fly על ידי
Sniffing או Hijacking ( יש לי סייגים פה ) אבל ניתן לגנוב את שם המשתמש והסיסמה שלי שמשודרים PLAINTEXT עוד לפני שהעברתי פרט אחד !!! אם לאותו CRACKER יש את השם משתמש והסיסמה שלי , הוא לא צריך לחפש את האשראי שלי , כי הפרטים כבר מולו !!!.
אתם מוזמנים לנסות בעצמכם , גשו לאתר המכירות האהוב עליהם , פנו לפריט מסויים שאתם רוצים לרכוש וחפשו את שדות המשתמש והסיסמה בעמוד. הם שם ? יפה ... והאם אתם רואים את המנעול הקטן של הSSL למטה ? לא ? מעניין ...
ישנם גופים אשר מתעוררים לבעיה זו , ועל סמך כך אנו יכולים לראות יותר ויותר אתרים שמקשים על ההזדהות , שמעבירים דרך כמה מסכי הזדהות , וחלקם אף הגיעו למצב המבוקש , בו לא ניתן להזין שם משתמש או סיסמה בעמוד שאינו SSL Encrypted.
אשמח לשמוע הצעות או רעיונות בנושא זה, אתם מוזמנים לכתוב.
Labels: architecture, ecommerce, issues, ssl
| Link 
חייבים להדגיש כאן נקודה לגבי עניין המסחר האלקטרוני וגניבת פרטים.
אני לא רואה סיבה רצינית לקראקר לשבת ולחפש שם וסיסמה כדי לפרוץ למשתמש אחד.
הרבה יותר רווחי ונכון לפרוץ לשרת הDB עצמו ומשם להוציא את הפרטים הדרושים ובמאסות, לא במשתמש יחיד בכל פעם.
ברוב המוחלט של המקרים לא מתבצעת גניבה של פרטים ע"י SESSION HIJACKING או ע"י MITM אל בניצול חולשות של האתר ובסיסי הנתונים שלו.
לסיום אני אדגיש עוד נושא - אם כל מה שאני רוצה זה כרטיס אשראי של משתמש אחד - הרבה יותר פשוט להאזין לטלפון של הפיצריה השכונתית שלו מאשר לחכות למצב בו הוא מזדהה באתר מכירות.
גם העונש הקבוע בחוק הוא קטן יותר :-)
Posted by
Anonymous |
12:35 PM
אגב..
מנגנוני התגובות פה מחרידים ביותר.
Posted by
Anonymous |
12:36 PM
מתרגלים ... לי עוד קשה ... אבל אני רוצה BLOGGER :)
בכל מקרה, אין ספק שSOCIAL ENGINEERING תמיד הרבה יותר קל בכל נושא שהוא , בטח ובטח מבחינת חוקי אבטחת המידע , קח למשל את ה Computer Crimes Act מ1987 שעדיין לא השתנה , אומר שפריצה לחשבונות אלקטרוניים מוגדר כפריצה פיזית. בעוד SE הינה רוחנית ולכן יש להתייחס לתקינות אחרות בתחום.
לצערי, עולם אכיפת אבטחת המידע בכיוון הLaw & Ethics בארץ נמצאת בראשית דרכה.
Posted by
barry |
12:43 PM
שלחתי לך תגובה במייל כי חסמו לי פה את התגובות
Posted by
Anonymous |
7:26 PM
היי עומר
הייתה בעיה בBLOGGER. שלדעתי תוקנה
נסה לשלוח שוב את הCOMMENT
ואני אמחק את הערות הביניים
תודה :)
Posted by
barry |
7:45 PM
ברצוני לצרף תגובה של עומר טרן שנשלחה אליי במייל :
אני חושב שאתה טועה בענק, אבל אני לא מתחייב. אביא את הנתונים ותשפוט לבד.
מבחינת אמון הציבור, מה שגורם אנשים לקנות זה לא האבטחה אלא גיבוי שנותנות חברות האשראי. היום זו עובדה, אך לפני עשור בארצות הברית היו ממש מסעות פרסום של חברות אשראי למדוע זה בסדר לקנות באינטרנט. אגב, בנק הפועלים נותן ללקוחות שלו אחריות מלאה על גניבת כספים מחשבון האינטרנט על בסיס אותו הגיון. זה לא
האבטחה, זה הביטחון.
מבחינת עניין ה-SSL, בדקתי בשלושה אתרים - p1000, olsale ו-וואלהשופס. חוץ מאולסייל השניים האחרים נראים לי בסדר. אני לא חושב שהם מצפינים את כל הדף, אלא מביאים חלונית מוצפנת לתוך דף לא מוצפן.
( קוד מקור מתוך האתרים שאינו עובר את הסינון של BLOGGER )
שים לב ל-https כשאתה עושה view source. באולסייל גם יש, אך הוא רק מפנה ל-thawte.
בקיצור, אם אני טועה, אנא תקן אותי.
עומר טרן.
Posted by
barry |
7:23 AM
ובכן אתה לא טועה , לא בכוונה לפחות.
יש נושא שלם של data conjesting וכמובן cookie tempering שבנויעל סמך אתרים כאלה
תחשוב איזה קל להאזין , לבצע MITM ולהחליף עוגיות... באתרי המסחר שרשמת לי בקור ( שהוסתר ) היו אכן הפניות לחלוניות מאובטחות בתוך אתרים , אבל הסביבה שהם רצים בתוכה אינה מאובטחת. כלומר , אם אני מריץAPPLET שרץ על עמוד , לא אכפת לי מאיפה החלונית ( ואותם אתרי מסחר אינם WEB2.0 ) אז די קל לי לבצע הקלטות של הדף
אחת השיטות הנפצות, היא לבצע CROSS SITE ולהשתיל KEYLOGGER ברמת הJAVA אשר מקליט כאשר אנו נמצאים בעמודים מסויימים.
זה עולם אפור :) כולנו יודעים זאת.
אז כמו שאמרתי , הקונספט הוא נכון , אתה צודק ב100% , לא ניתן לשבור את הSSL וישנם אתרים רבים אשר מבצעים אימפלמנטציה של הכנסת חלון מוצפן לתוך אתר שלם ... יופי ... האם אותו עמוד מוגן נגד התקפות ?
Posted by
barry |
7:27 AM
למרות שאני חושב שזה מסוכן שלא מצפינים את שם המשתמש ואת הסיסמא, דווקא ברוב הפעמים זה לא מסכן את חשבון הבנק. רוב האתרים המסחריים מבקשים בכל קנייה וידוי נתונים של פרטי הכרטיס (מספר+תוקף) ככה שהפרטים האלה לא ממש מולו.
Posted by
Anonymous |
3:21 PM
ובכל זאת, לא נראה לי שאני טועה. כל המתקפות שתיארת חלות גם על דף SSL. ניתן להריץ script גם בדף SSL שיאזין להקלדות המשתמש, ישלח את ה-cookie וכדומה (האמת שאני לא מכיר keylogger בסקריפט, זה נראה לי מעבר ליכולות שפות הסקריפטינג, אבל אני לא חותם על זה).
אני לא רואה איך SSL על כל הדף מתמודד מול המתקפות שאתה מציין ובכלל תורם בצורה מהותית לאבטחה. למעט העובדה שלא ניתן להבדיל בין אתרים מאובטחים ללא מאובטחים בלי להיכנס לקוד, שזו סוגיה שקשורה יותר לחינוך משתמשים.
Posted by
Anonymous |
6:06 AM