BinaryVision

Tag: SQL

למה מתייחסים לSQL שונה?!

by on יול.14, 2009, under כללי

הקדמה
קיימים הרבה מאוד סוגים של פרצות אבטחה, לדוגמא XSS, אני יכול להבין למה XSS קורה, הרי לפעמים יש מקרי קצה שבהם רוצים לתת למתכנת יכול לכתוב html, או לחלופין, קשה לבקר (לא באמת, אבל נניח) כל כתיבה שאנחנו מבצעים ולכן אפשר לפספס ובטעות לכתוב מחרוזת ששכחנו לעשות לה escaping.
אותו דבר אני יכול להגיד על buffer overflow (גם לא באמת, אבל נניח) וישנן עוד הרבה פרצות שעליהן אפשר להגיד אותו דבר (לפעמים המצב עגום יותר ולפעמים פחות).
אבל במקרה של sql injection אני פשוט לא מבין איך זה עדיין קיים. אבל לא על זה מדובר בכתבה, אלא על הבעיתיות והקלת הראש שאנשים מייחסים לשרת sql שלהם.

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

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

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

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

הבעיה האמיתית ופתרון בשבילה
הפתרונות שהצגתי כמובן נפוצים ומשתמשים בהם בכל מיני מקומות, והם הדרך לטיפול בבעיה, אבל לא מעט פעמים נתקלים בכל זאת בפרצות. אבל זה בהחלט לא מספיק!
הבעיה האמיתית היא, איך בכלל הגענו למצב שבו כל מה שאנחנו צריכים זה לקרוא מידע מ"טבלאת הידיעות של האתר" ובכל זאת יש לנו הרשאות כתיבה\קריאה ל\מטבלאת המשתמשים?
כל איש אבטחה יודע שהדבר הראשון שעושים זה "הפרדת סמכויות" כי בסופו של דבר, לא משנה כמה ה firewall שלך חוסם כל תעבורה וכל התוכנות שאתה משתמש בהן לא פגיעות, אם ל guest account שלך יש הרשאות root, יהיה לך גהנום בשרת 🙂
בכל שרת sql בתחום יש שמות משתמש וססמאות, יתרה מכך, לכל שרת יש תמיכה באפשרויות הגבלת גישה מתקדמות.
אז למה אנשים לא משתמשים ב user אחד בשביל לקרוא\לכתוב מהטבלאת משתמשים, ביוזר אחר בשביל לקרוא מידע וביוזר אחרון בשביל לכתוב מידע? (כאשר מידע = הכל חוץ מטבלאות משתמשים) או אפילו אם צריך לפצל את זה עוד יותר (לדוגמא מידע אישי רגיש יהיה מפוצל מהבלוג של האתר).

ההנחה שלי היא: עצלנות.

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

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

הערה חשובה:
אני יודע שלא תמיד יש לכם גישה ליצירת גישות (לדוגמא שרת חינמי) אבל כל עוד אתם משלמים על השרת, זכותכם לדרוש כמה יוזרים שתרצו! ככה שזה לא תירוץ!!!

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

23 Comments :, , , , more...

מחפש משהו?

תשתמש בטופס למטה כדי לחפש באתר: