הגנת IPS כנגד SQL Injection , לא ממש...
אני אוהב לדבר על מערכות ניתוח תעבורה , ניתוח השכבות ופירוק האפליקציה והפרוטוקולים לגורמים תמיד ריתקו אותי ונתנו לי נופך לעבודתי במרוצת השנים. ועם הכל די התמחיתי בכלי ניתוח התעבורה השונים אשר התחילו מבדיקות RFC למערכות IPS מתוחכמות מבוססות אנומאליה\חתימות דרך אנטיוירוסים רשתיים וכלה כמובן במערכות ניתוח תעבורה לשכבות האפליקציה .
אחד הדברים שתמיד הפתיעו אותי הוא התפיסה הרווחת ( והמוטעית ) אשר אומרת שניתן לחסום SQL Injection במערכות IPS או מערכות FW מתקדמות עם מנגנוני חתימות. ואני כמובן מוחה.
התפיסה היא שעל ידי חיפוש של מחרוזות גנריות בתוך שאילתות HTTP למיניהן , ניתן לאתר את כל\רוב סוגי התקפות הSQL השונות. אך האם כך הדבר ?
משפט SQL הוא משפט אשר עובר Parsing מסויים ולבסוף מעובד על ידי מנגנוני קלט אשר בודקים את תקינותו מבחינת Syntax וקישורו לאובייקטים קיימים בDB , על אותה רגל - משפט SQL Injection יהיה לעולם משפט אשר מנסה לקיים תנאי TRUE. על ידי כך במידה ויש התאמה לתנאי , השאילתה אשר מפיק משפט הSQL תרוץ על השרת...
ואם מדובר במשפטי TRUE ... אז משפט כמו 1=1 הוא נכון , וגם a=a הוא נכון , וגם 100<999 הוא נכון וכן הלאה ... כלומר במילים אחרות --> לא ניתן לייצר חתימה אשר תתפוס כל SQL Injection אלא את הבסיסיים בלבד.
או אולי , לפי הקונספט של לחפש את תווי הגרש ( ' ) בתוך מחרוזת ... והאם השמות "ג'ק" או "ג'ון" אינם שמות הגיוניים ? מובן שכן, ומתוך תפיסה חתימתית - לא יהיה ניתן להזין שמות כאלו לדף מאחורי IPS חתימתי שכזה ...
Labels: code, consulting, hacking, imperva, sql, threats
| Link 
שמחתי לקרוא מאמר(ון) שמשתדל לא לעשות סלט בין עברית לאנגלית, של כותב המקפיד לכתוב מילים עבריות בעברית ואנגליות באנגלית (כיון שאין מילה בשם סינטקס, אבל יש מילה שנקראת syntax), אך גם זה לרוב לא מודייק, כיון שאם המאמר הוא בעברית, למה לא להשתמש במילים שכולם (במידת האפשר - כשיש תרגום נכון) בשפת המאמר?!
לדוגמה:
Parsing = ניתוח - "שפט SQL הוא משפט אשר עובר Parsing מסויים ולבסוף מעובד על ידי". משפט sql מנותח ע"י ולאחר מכן מעובד...
Syntax = תחביר - "מבחינת Syntax". מבחינה תחבירית.
"קיימים בDB" - קיימים במסד הנתונים.
ובענין תוכן הכתוב:
1. אשמח לדעת למה אתה קורא IPS.
2. אני חושב שעיקר ההגנה היא לבדוק אם לא מנסים להתחכם בסגירת מרכאות ופתיחת זוג מרכאות חדשות, כיון שלרוב, הקלט מהשתמש הוא מחרוזת שאמורה להיות משורשרת בתוך משפט sql ולכן צריך רק במקרים כאלו רק לוודא שהמשתמש לא ניסה לתחום את המחרוזת במרכאה כדי לסיים את המשפט ולפתוח משפט חדש.
ישנם מקרים פשוטים יותר כגון מקרים בהם צפוי לקבל ערך מספרי, כך שמספיק להמיר את הערך שהתקבל למספר בטווח הצפוי ואז אין ממש סיכוי לבעיה.
מקרה נוסף הוא כשהקלט מהמשתמש אמור לבחור אפשרות אחת מתוך מס' אפשרויות לא רב, כך שניתן לוודא שהקלט הוא אחד מ-x אפשרויות קבועות (ולעתים גם דינאמיות, אך כאן זה כבר פחות פשוט).
ישראל
Posted by
Anonymous |
6:53 PM