Photo-1

אבטחת מידע





אבטחת מידע באינטרנט הוא תחום חשוב ביותר בתחום בניית האתרים אך הפחות מיושם בקרב האתרים הקטנים ואתרי התדמית  .

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

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

*כל קטעי הקוד נכתבו ב PHP.

 

XSS - Cross-site scripting

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

כיצד מונעים התקפות XSS?

יש לוודא שכל שדות הקלט מסוננות בצורה תקינה 

לדוגמא :

עבור קלט מספרי בלבד יש לוודא שהקלט מכיל אך ורק מספרים

preg_replace("/[^0-9]/","", $string)

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

preg_replace("/[^א-ת0-9?! ]/",'',$string)

 

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

 

SQL injection

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

כיצב מתגוננים מפני התקפות SQL injection?

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

 

CSRF - Cross-site request forgery

התקפה מאוד פופלרית בקרב האקרים אך כמעט ואינה ידועה בקרב בוני אתרי התדמית או האתרים הקטנים.

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

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

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

https://danasbank.co.il/transfer.php?to=55555&sum=100

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

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

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

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

איך מתגוננים מפני התקפות CSRF?

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

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

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

 

שימוש בקוד פתוח ( ג'ומלה ,דרופל, וורדפרס וכו)

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

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

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

איפה הבשורה שלנו?

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

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

 

לא רק מדברים 

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