Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
32 Cards in this Set
- Front
- Back
|
Injection |
השתלת (הזרקת) קוד זדוני במקום בו מתאפשרת הזנתתוכן ע"י המשתמש. |
|
|
SQL injection |
התוקף מנצל את הטפסים שהשרת מאפשר למשתמש למלא ושותל קוד זדוני באחד מהשדות בטופס. למשל, עבור טופס ביצוע login שיש להזין לו מייל וסיסמא, אם התוקף יזין בשדה המייל את המחרוזת "John@Dow.com’ or 1=1--", התשובה תמיד תהיה true, בשל ה- "or 1=1",וכיוון שמה שיבוא לאחר ה- "--" אלו הערות, כלומר קוד שלא מורץ/נבדק. בבדיקה מול מסד הנתונים, כל השורות יקיימו את התנאי וכולן יחזרו, וכך התוקף יצליח להתחבר לאתר מבלי שהוא יודע מייל וסיסמא, וקיבל הרשאות וגישות למידע. |
|
|
טכניקות שימושיות |
- שימושב- "--" על מנת להפוך את כל מה שבא לאחר מכן להערה. - התחמקות מהחלפות טקסט שנועדו להגנה למשל ע"י drdropop - כתיבת הערך האסקי של התו במקום התו עצמו -התחמקות ממניעת כתיבת רווחים בשדה מסוים ע"י שימוש בסוגריים במקום רווחים ניסיון לקבל מידע על בסיס הנתונים, למשל ע"י שרשור שאילה ב- union שמדפיסה את הגרסא הנוכחית והמשתמש הנוכחי של מסד הנתונים: ?id=2 union select user(),version() |
|
|
Blind SQL Injection |
תוקפים נוהגים להתבסס על הודעות השגיאה שהשרת מחזיר להם במטרה להצליח בהזרקת הקוד הזדוני. אולם ישנם מקרים בהם השרת לא מחזיר הודעות שגיאה, אלא רק תגובות true/false. במצבים אלו, ניתן לבצע, למשל, שאילתה שמטרתה מציאת הסיסמא של שם משתמש ידוע, ע"י ניחוש תו תו של הסיסמא והפעלת מנגנון השהייה; אם ניחוש התו הראשון יהיה נכון, תיווצר השהייה של x שניות, אחרת - נקבל תשובה באופן מיידי (גם אם זו תשובה "ריקה"), ללא השהייה, ונבין שטעינו בניחוש התו הראשון. נמשיך כך עד שנמצא את הסיסמא במלואה. |
|
|
Url Injection |
הזרקת קוד זדוני ב- URL שישפיע על הדף הנטען. הקוד הזדוני עלול להשפיע על השרת ועל הלקוח. נשים לב שפגיעה בצד השרת תגרום לפגיעה בכל המשתמשים הפונים לשרת הזה. פגיעה בלקוח ספציפי יכולה להתבצע למשל ע"י שליחת לינק שפתיחתו תפעיל קוד זדוני. |
|
|
HTML Injection |
URLRedirection - השתלת קוד זדוני בעמוד HTML שיגרום לכך שכל מי שייכנס לאתר יועבר ללינק המצוין בסקריפט. |
|
|
התמודדויות עם הזרקות Parameterized queries - Prepared statements |
הכנסת הקלט המוזן ע"י המשתמש לתוך משתנים ורק לאחר מכן יבוצעו שרשור לקוד השאילתה והרצה. זהו מנגנון שיודע לבנות את המחרוזת באופן שמגן מקוד זדוני. |
|
|
התמודדויות עם הזרקות Parameterized queries - Stored procedures |
שימוש בשאילתות מוכנות מראש, ואז במקום להריץ שאילתה אנו מריצים פונקציה באופן מבוקר שימנע הרצת קוד זדוני |
|
|
התמודדויות עם הזרקות Input validation - Regular expression |
בדיקות תקינות קלט. נבצע אותן בצד השרת, כיוון שבצד הלקוח הן ניתנות לעקיפה. |
|
|
התמודדויות עם הזרקות Input validation - Sanitizing and escaping |
"חיטוי" הקוד, נטרול הזדוניות בקוד ע"י חיפוש של מילים ו/או תווים מזיקים בקלט והסרתם/החלפתם. |
|
|
התמודדויות עם הזרקות Input validation - Error handling |
אי פירוט השגיאות ללקוח, הצגת עמוד שגיאה כללי שלא חושף מידע. |
|
|
התמודדויות עם הזרקות Whitelisting and Blacklisting |
???
|
|
|
התמודדויות עם הזרקות Least Privilege |
מזעור ההרשאות למסדי הנתונים בסביבה שלנו, הימנעות ממתן הרשאות admin למסד הנתונים, מתן הרשאות קריאה בלבד למי שלא זקוק למעבר וכו'... |
|
|
התמודדויות עם הזרקות httpOnly Cookies |
מניעת גישה ל- cookies ע"י document.cookie.p |
|
|
Session Hijacking - SessionFixation |
במטרה להישאר ידידותיים למשתמש, שרתי web לא מכריחים את המשתמשים לבצע אימות לפני כל צעד שהם מבצעים. ברגע שהתבצע אימות ראשוני, השרת מייצר "אסימון" זמני ורנדומלי (המשמש כמפתח בעל אורך חיים מסוים) ושולח אותו למשתמש. המשתמש חייב להשתמש באסימון הזה בבקשות הבאות שלו מהשרת ובתגובה השרת יבדוק את האסימון ויחליט בהתאם האם לאשר את הבקשה או לדחות אותה. השימוש באסימון בבקשות הלקוח נעשה ע"י cookies. כשאורך החיים של האסימון עובר, על המשתמש לבצע שנית הזדהות עם שם משתמש וסיסמא ולקבל אסימון חדש. |
|
|
Session Hijacking - SessionFixation איך ניתן לנצל לתקיפה? |
תוקפים יכולים לנצל זאת ולהיכנס לסשן פתוח בין שרת ללקוח; התוקף נכנס לאתר ומבצע הזדהות, הוא מנצל את העובדה שה- sessionid מופיע ב- url ושולח לקורבן את ה- url הזה. הקורבן נכנס ללינק ומבצע הזדהות עם הפרטים האישיים שלו, התוקף מתחבר ל- sessionid ונכנס לחשבון האישי של הקורבן. |
|
|
SOP (Same Origin Policy) |
מנגנון שחוסם גישה ממקור מסוים לתוכן שמגיע ממקור אחר. המקור מוגדר ע"י שרת, פרוטוקול ופורט. |
|
|
XSS (Cross Site Scripting) |
בעקבות ה- SOP, סקריפט שמקורו בדומיין A לא יכול לגשת לפרמטרים של דומיין B,למשל ל- cookies. עם זאת, אם דומיין B יותקף, הדפדפן לא יזהה שמדובר בקוד זדוני ולא ימנע ממנו גישה לפרמטרים של B. |
|
|
סוגי XSS Stored XSS |
התוקף הצליח להרעיל את שרת ה- web עם קוד זדוני, וכעת כל לקוח שניגש לשרת ונכנס לדף הפגוע, גורם להרצת הקוד הזדוני על הדפדפן שלו. |
|
|
סוגי XSS Reflected XSS |
הלקוח הקורבן ניגש לשרת ה- web בדרך ספציפית שגורמת לכך שבתגובה הוא יקבל את הקוד הזדוני. למשל - הפנייה לעמוד עם הודעת שגיאה שתוקף שתל בו הרצת קוד זדוני. |
|
|
סוגי XSS |
הקוד הזדוני לא נמצא בתגובת השרת ללקוח, אלא מורץ עלה- DOMבשרת.(DOM - Document Object Model - ייצוג אובייקטים בעמוד ה- HTMLע"פ היררכיה). |
|
|
איך עובד תהליך DNS Rebinding |
1. הקורבן נכנס לאתר של התוקף. 2. האתר שולח לקורבן את ה- IP של הדומיין עם TTL נמוך (על מנת שלא יימצא ב- cache של ה-DNS) 3. בזמן זה הקורבן מספיק להוריד את הקוד הזדוני שלאחר מכן גם יורץ. 4. הקוד הזדוני יגרום לכך שתישלח בקשת DNS ל- NS של האתר, והתגובה שתגיע תהיה עם IP שונה, של אתר אחר, אך באותו הדומיין (על מנת שה- SOP לא ימנע זאת). 5. לתוקף יש גישה לאתר השני שנפתח אצל הלקוח, כיוון שמבחינת הדפדפן מדובר באותו המקור. |
|
|
DNS Pinning |
פתרון להתקפה DNSRebinding - הדפדפן ישמור את כתובת ה- IP ויאשר גישה רק לכתובת ה- IP הזאת. הדפדפן בעצם יתעלם מה- TTL וימנע גישה מאוחרת לשרת ה- NS של האתר. |
|
|
Web Attacker |
התוקף יכול לרכוש שטח אחסון ולאחסן בו אתר המכיל קוד זדוני. כל לקוח שיפנה לאתר הזה יגרום להורדת הקוד הזדוני אצלו במחשב ולהרצתו. התוקף יכול לגרום ללקוחות לפנות לאתר הזדוני שלו ע"י הצעת שירותים חינמיים שמושכים לקוחות (צפייה ישירה בסדרות, הגרלות...), שליחת לינקים מזויפים במיילים (phishing) וכדומה. |
|
|
Network Attacker |
Passive - האזנה לתעבורה, זיהוי קורבנות פוטנציאליים וניסיוןתקיפה. Active - השתלטות על ראוטר/התחזות לראוטר אחר על מנת להשיגשליטה על התעבורה. |
|
|
Malware Attacker |
התוקף יכול להוביל להתקנת נוזקות על המחשב שלהקורבן באמצעות ניצול פרצות ידועות וע"י כך שהוא משכנע אותו להתקין תוכנותשמתחזות לתוכנות אחרות ("אנטי וירוס"). |
|
|
JavaScript |
זוהי שפה שמורצת ע"י הדפדפן, והיא יכולהלרוץ בכל זמן - לפני שדף ה- HTMLנטען, לפני שהעמוד מוצג, תוך כדי שהעמוד מוצג, לאחר שהמשתמש יצא מהעמוד... משתמשיםבה לבדיקת תקינות קלט בטפסים, לחישובים מתמטיים, ליצירת אפקטים וכדומה. |
|
|
מה הן הגישות לכתיבת JavaScript באתרים? |
- הטמעת הסקריפט בתגית. דוגמה: <script>alert("Hello World!")</script> -הפרדת הסקריפט מהתגית עצמה והגדרת sourceממנו יש להוריד את הקובץ עם הסקריפט ולהריצו. דוגמה: <script type="text/JavaScript" src="function.js"></script> -הפעלת סקריפט בעקבות אירוע (כמישהו ירחף עם העכבר עלהלינק - הסקריפט יופעל). דוגמה: <a href="http://www.yahoo.com" onmouseover="alert("hi");"> השתלתסקריפט במקום לינק. דוגמה: <a href="JavaScript: alert('You clicked');">Click me</a> נשים לב שכאשר אנו מייבאים ספריות קוד JavaScript ממקור אחר, ההתייחסות אליו תהיה כקוד שנטען מהאתר בו אנו מריציםאותו (האתר שלנו), ולמעשה מדיניות Same-origin (SOP) לא תבוא לידי ביטוי כאן. |
|
|
איך נשתמש ב-JavaScript לטובת Reflected XSS? |
1. הקורבןנכנס לאתר לגיטימי (שכנראה לא מאובטח באופן מירבי). 2. הקורבןמבצע באתר הזדהות עם שם משתמש וסיסמא ומקבל cookies; כל שאר הבקשות שלו באתר ייעשו ע"י צירוף ה- cookies לשם אימות ואישור. 4. עםכניסתו לאתר התוקף, הקורבן גורם להורדה של עמוד HTML המכיל סקריפט זדוני, שמוביל לפתיחת frame עם כתובת האינטרנט של הדומיין המותקף. בפרמטר name שהכתובת צריכה לקבל, התוקף שותל קוד זדוני שמורץ אצל הלקוח וגורםלפתיחת הלינק. 5. כעת,הדפדפן מעבד את הנתונים שהגיעו מהלקוח על מנת להציג אותם עבורו (למשל, אם בפרמטרהיינו שמים את השם "Avi",הדפדפן היה מציג לנו "Hello, dear Avi"). מבחינת הדפדפן, הסקריפט הגיע מהדומיין של הלקוח ולכן הואיכול לגשת ל- cookies שלו(עוקף את ה- SOP). 6. לתוקףיש גישה ל- cookies שלהקורבן מה שחושף אותו למידע רגיש שלא יועד לו. |
|
|
XSRF (Cross Site RequestForgery) |
זיוף בקשות ע"י סקריפטים.הקורבן ניגש לשרת של אתר לגיטימי, פותח סשןומבצע הזדהות. במקביל, הוא נכנס לאתר של תוקף. הכניסה לאתר התוקף מובילה להורדתסקריפט זדוני אצל הקורבן, שגורם לבקשות מזויפות להישלח כביכול ממנו אל השרת. SOP לא בא לידי ביטוי כיוון שמדובר בבקשה בלבד ולא בניסיון לשליפתמידע, ולכן הכל מאושר. הבקשות המזויפות מכילות את ה- cookies של הקורבן ולכן השרת מאשר אותן. הבקשות הללו יכולות להיות למשל העברתכספים באתר של בנק, איסוף מידע על אנשי קשר וכו'...מכאן ניתן להסיק שאימות על בסיס cookies בלבד אינו מספיק. |
|
|
איך נתמודד עם זיוף בקשות ע"י סקריפטים? |
- שימושבשדה hidden שמכיל "אסימון" סודי לצורך אימות - בדיקתמקור הבקשה ע"י השדה "referrer",אם הכתובת לא מתאימה ללקוח - הבקשה לא תבוצע. - שימושב- headers ייעודיים, שלא ניתנים לזיוף, לצורך אימות |
|
|
XSS vs. XSRF |
XSS: - המשתמשסומך על אתר שממומש באופן לא טוב. - התוקףמזריק סקריפט לאותו אתר שהמשתמש סומך עליו. - הדפדפןשל המשתמש מריץ את הסקריפט הזדוני תחת הדומיין של האתר שהמשתמש סמך עליו. XSRF: - אתרשממומש באופן לא טוב סומך על המשתמש. - המשתמשגולש לאתרים זדוני של תוקף שגורם להורדת קוד זדוני. - הדפדפןמריץ את הקוד הזדוני ומבצע את "בקשות המשתמש" המזויפות. |
