התפקיד הקריטי של הנדסת אבטחה ביקורת בפיתוח מודרני

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

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

Vulnerabilities נמצאו במהלך ביקורת

SQLזרקה (SQLi)

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

במהלך ביקורת, ניתן לזהות הזרקת SQL על ידי סקירה של קוד עבור בנייה דינמית של שאילתה, בחינת לוגיקה אימות קלט, ובדיקה עם עומסים כי גורמים שגיאות מסד נתונים או עיכובים זמן. ORMs (Object-Relational Mappers) להפחית את הסיכון אך לא לחסל אותו לחלוטין; מפתחים חייבים עדיין להבטיח שאילתות גלם מטופלים בבטחה.

Cross-Site Scripting (XSS)

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

רואי חשבון אבטחה מחפשים מקומות שבהם קלט המשתמש (מפרמטרי כתובת URL, הגשת טופס או תוכן מסד נתונים) מוכנס לתוך HTML, JavaScript, CSS, או SVG ללא בריחה נאותה.סורקים אוטומטיים יכולים לזהות רבים וקטורים XSS, אבל סקירה ידנית חיונית לתרחישים מורכבים מעורבים מסגרות JavaScript שמשמרנים את DOM synchronly.

חוסר ביטחון ושיקום

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

במהלך ביקורת, בודקים בודקים מדיניות סיסמה, דור אסימונים, תכונות עוגייה מאובטחות (Htp Only, Secure, SameSite), ומימוש אימות רב-ספק (MFA) הם גם לאמת כי זרימת עבודה של איפוס סיסמה אינה רגישה לזיהום או ליירוט.

בקרת גישה שבורה

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

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

אבטחה Misuration

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

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

חשיפה למידע רגיש

פגיעות זו כרוכה בהגנה לא מספקת של מידע רגיש כגון מספרי כרטיסי אשראי, מספרי אבטחה חברתיים, רשומות בריאות או אישורי אימות.גורמים נפוצים כוללים העברת נתונים על קשרים לא מקודמים (HTTP במקום HTTPS), אחסון נתונים עם הצפנה חלשה, תוך הסתמכות על פרוטוקולים קריפטוגרפיים מיושנים (TLS 1.0/1.1), או מחיקת מידע רגיש בטקסט פשוטו.

במהלך הביקורת, מפקחים לאמת כי הצפנה מוחלת הן במעבר והן במנוחה, כי נהלי ניהול מרכזיים מאובטחים, וכי נתונים רגישים אינם חשופים באופן בלתי נמנע באמצעות תגובות שגיאה, פרמטרים של כתובת האתר, או היסטוריה של הדפדפן. Compliance with סטנדרטים כמו PCI-DSS, HIPAA, או GDPR מוסיף דרישות נוספות להגנה על נתונים.

Cross-Site Request Forgery (CSRF)

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

אודיטורים בודקים את הסימון נגד גירסאות של בקשות לשינוי המדינה (POST, PUT, DELETE), להעריך את השימוש בתכונות של קבצי Cookie באותו אתר, ולהבטיח כי פעולות רגישות דורשות אימות חוזר או אישור.מסגרות מודרניות לעתים קרובות כוללות הגנה על CSRF מובנה, אבל מפתחים יכולים שלא ניתן למנוע או לא לשנות אותו.

שימוש ב-Commonents with known Vulnerabilities

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

במהלך ביקורת, כלי ניתוח של תוכנה (SCA) משמשים ליצירת הצעת חוק של חומרים ודגל כל רכיבים עם פרצות ידועות.הביקורת גם על התהליך עבור ניטור ותיקון של תלות, להבטיח כי עדכונים מוחלים במהירות.

כיצד לתקן את הפגיעות

אספקת SQL

  • (FLT:0)Use הכין הצהרות ושאילתות פרמטריות באופן בלעדי.IRLT:1) זה מפריד בין לוגיקה SQL מהנתונים, מה שהופך את הזרקת SQL לבלתי אפשרית ברמת הנהיגה של מסד הנתונים.עבור שאילתות בנויות באופן דינמי, להשתמש בהליכים מאוחסנים או בוני שאילתה של ORM שיוצרים הצהרות פרמטריות.
  • (FLT:0)Validate ו-Ssanitize את כל קלטות המשתמשים.FLT:1 בעוד פרמטריזציה היא ההגנה העיקרית, אימות קלט (למשל, לדחות דמויות בלתי צפויות, הגבלת אורך אש) מוסיף שכבה שנייה ומונע סוגים אחרים של זריקה.
  • (FLT:0) זכויות מסד הנתונים של לימיט (Limit Database Productivity) .FLT:1hil Applications צריך רק את הרשאות המינימליות הדרושות - לא DROP TABLE או CREATE USER מענקים.
  • (FLT:0) הפעלת חומת אש של יישום אינטרנט (WAF) עם חתימות הזרקת SQL.Ruve:1 זה מספק רשת בטיחות, אך לא צריך להחליף שיטות קידוד נאות.

צילום: Cross-Site Scripting (XSS)

  • (FLT:0)Escape פלט נתונים בצורה נכונה על פי ההקשר.I.veFLT:1) השתמש בספריות טבילה רגישות בהקשר (למשל, OWASP Java Encoder, Microsoft AntiXSS). תוכן דינמי HTML-escape שהוכנס לתכונות HTML, תוכן JavaScript-escape שהוכנס להקשרים של תסריטים, ו-URL-enקוד קוד בשימוש ב-href/src.
  • (FLT:0) מדיניות אבטחת תוכן (CSP) ראשי התיבות של FLT:1 CSP מגבילה את התסריטים יכולים לבצע, לחסום ביעילות את השורה, את הסגלגל ואת התסריטים ממקורות שאינם בוטחים.התחל עם מדיניות מגבילה ומפקח על הפרות.
  • (FLT:0)Validate ו-Ssanitize קלט משתמש בצד השרת.Felo1 השתמש ברשימות עבור דפוסים צפויים (למשל, שדה שם צריך להכיל רק אותיות ומרחבים) ולפרש תגי HTML מסוכנים כאשר טקסט עשיר מותר (שימוש בספריה חזקה כמו DOMPORify).
  • (ב) ,0) ,5 ,5 ,5 ,5 ,5 , ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇

חיזוק האותנטיות וניהול ה-Switch

  • (FLT:0) מדיניות סיסמה חזקה כוח.FLT:1ua דורש אורך מינימלי (לפחות 12 תווים), מורכבות, ובדוק נגד רשימות סיסמה נפוצות. השתמש במשחתת כוח סיסמה כמו Zxcvbn.
  • (FLT:0) ,Implement multi-factor אימות (MFA)IRFLT) 1:1 סיסמאות חד פעמיות מבוססות זמן (TOTP), קודים SMS, או מפתחות אבטחת חומרה מוסיפים שכבת הגנה קריטית, גם אם סיסמאות נפילות.
  • (FLT:0) Use מאובטח סיסמה ישing.FIRLT:1 ; בחר bcrypt, ארגונו 2, או PBKDF2 עם גורם עבודה גבוה.לעולם אל תאחסן סיסמאות בטקסט רגיל או להשתמש אלגוריתמים מהירים כגון MD5 או SHA-1.
  • (FLT:0) הסרת חשבון וקצב הגבלת .IRLT ( 1 Lock) לאחר 5-10 ניסיונות כושלים לתקופה, ולהשתמש ב CAPTCHA או עיכובים מתקדמים להתקפות כוח רוטט.
  • (ב) [15] , ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇

תיקון בקרת גישה שבורה

  • (FLT:0) גישה לפקדים על השרת לצד השני.FIRLT:1 לעולם לא להסתמך על בדיקות בצד הלקוח (למשל, כפתורים מסתתרים) כשליטה היחידה.כל בקשה חייבת לוודא שהמשתמש מורשה למשאב הספציפי ולפעול.
  • (ב) ,0) ניתן לקבל מסגרת אישור עקבית.FLT:1 , מרכזי בבדיקות אישורים במתווך או שירות אישור ייעודי במקום לפזר אותם על פני בקרים.
  • Adopt role-based access control (RBAC) or attribute-basedaccess control (ABAC). Define roles clearly and test every endpoint to ensure that users cannot escalate privileges.
  • (FLT:0) ,Eliminate insecure Object Reference (IDORIR) 1 השתמש במפות אובייקט עקיפות (למשל, UUIDs או אסימונים) במקום מזהה מסד נתונים של מסד נתונים ב-URL ותשובות API.
  • (ב) [15] ,"התחילה" (ב)"ב"ה) כל נקודת מוצא שלא מעניקה במפורש גישה צריכה להחזיר תגובה אסורה 403, ולא רק להשמיט את הנתונים.

הפעלת אבטחה Misconfiguration

  • (FLT:0) Harden allסביבותיה.FLT:1 Remove חשבונות ברירת מחדל, לשנות את האישורים ברירת המחדל, שירותים מיותרים ונמלים מיותרים, ולהשתמש בתצורה בטוחה ברירת מחדל עבור מסגרות לשרתים.
  • (FLT:0) תצורה אוטומטית סריקה של תצורה אוטומטית תצורה של תצורה תצורה (FLT:1) שימוש בכלים כמו CIS-CAT, OpenSCAP, או ניהול יציבה בענן (CSPM) כדי לזהות סטיית מקווי בסיס.
  • (FLT:0) צמצום הדליפה של מידע.FLT:1) לכבות הודעות שגיאה פועליות בייצור, רישום דירקטוריאלי, להסיר נקודות קצה או ניהול.
  • (FLT:0) שמור תוכנה עד כה.FLT:1ir החלת תיקון אבטחה במהירות ומנוי ליועצים פגיעים עבור ערימה שלך. השתמש בדימויים של מיכל וניהול פגיעות עבור תשתיות.
  • (FLT:0) ככל הנראה העיקרון של זכות לפחות לכל משאבי הענן.FLT) 1 השתמש בתפקידי IAM עם הרשאות מינימליות, להגביל את הגישה לרשת עם חומות אש וקבוצות אבטחה, ומאפשר כניסה לכל הפעולות האדמיניסטרטיביות.

הגנה על נתונים רגישים

  • (FLT:0) מידע על העברת נתונים ב-HSTS.FLT:1; אנו מספקים HTTPS עם TLS 1.2 או גבוה יותר באמצעות ciphers חזק. השתמש ב-HSTS ראשי תיבות כדי למנוע התקפות מופחתות.
  • (FLT:0) נתוני קידוד במנוחה.FLT:1 השתמש ב-AES-256 או חזק יותר עבור נתונים מאוחסנים.ניהול מפתחות הצפנה באופן מאובטח עם שירות ניהול מפתח (KMS) וסובב את המפתחות מעת לעת.
  • (FLT:0) Tokenize או מסיכה נתונים רגישים.FLT:1 הקטנת כמות הנתונים הרגישים מאוחסנים, ולהשתמש אסימוניזציה או הצפנה מתאימה עבור נתונים כגון מספרי כרטיס אשראי.
  • (FLT:0) יומני אבטחה וטיפול בשגיאה.FIRLT:1 לעולם לא להזין מספרי כרטיסי אשראי, סיסמאות או אסימונים של מושב.Sitize הודעות שגיאה כדי להימנע מחשיפת פרטים פנימיים.
  • (FLT:0) ,Implement data סיווג ושמירת מדיניות .IRLT:1) לדעת מה הנתונים שיש לך, לסווג אותם ברגישות, ולמחוק נתונים שכבר אינם נדרשים.

מניעת CSRF

  • (FLT:0) אסימונים אנטי-CSRF (S.veFLT:1) כוללים אסימוני ייחודי ובלתי צפוי בכל צורה משתנה או בקשה.
  • (ב) תכונת העוגייה של אותו אתר ל-Strict או Lax.FLT:1 זה מונע עוגיות מנשלחות עם בקשות מעברי-אור, ובכך חוסמת ביעילות את רוב התקפות CSRF.
  • (FLT:0) Re-authentication for Critical Actions.FLT:1 for סיסמה שינויים, העברות כספים או דפי חשבון, מה שגורם למשתמש להיכנס מחדש לסיסמה או להשתמש ב- MFA.
  • (ב) [ה]הבא [ה] [ה] [ה]] ב[[המאה ה-20]], אך לא היה זה אלא מבדיל בין היתר ל[[המאה ה-20]].

ניהול סיכונים של צד שלישי

  • (FLT:0) , חייב חוק תוכנה מדויק של חומרים (SBOM) .Felo: 1 ממציאים כל תלות ישירה ועברית עם הגרסאות שלהם.
  • (FLT:0) סריקה אוטומטית תלותית של תלות.FLT1 כלי SCA (למשל, OWASP תלות-Check, Snyk, GitHub Costabot) לתוך צינורות CI /CD שלך כדי לדגל פרצות ידועות.
  • Update dependencies regularly. Applysecurity patches within a defined timeframe (e.g., 72 hours for critical CVEs). Set up automated pull requests for non-breaking updates.
  • (ב) עיין בספריות של LT:0 (Evaluate Library לפני אימוץ.FreaLT:1) בבדיקת תחזוקה אקטיבית, תמיכה קהילתית ותיעוד מעקב אבטחה.
  • (FLT:0)Considering or Locking.miaFLT) 1 השתמש בקובץ מנעול (למשל, חבילה-lock.json, דרישות.txt) כדי למנוע עדכונים מפתיעים לאמת את השלמות עם בדיקות.

בניית פוסט אבטחה פעיל

Fixing vulnerabilities after they are uncovered is necessary, but a mature engineering organization should strive to prevent them in the first place. Security audits are most effective when combined with a culture of secure coding, continuous education, and automated guardrails.

שינוי עם אימון מאובטח

כל מפתח צריך להבין את OWASP Top 10 וכיצד להימנע ממלכודות נפוצות. אימון ידיים קבוע והנחיות קידוד מאובטח לעזור להטביע אבטחה לתוך תהליך הפיתוח. כלים כמו linters עם כללי אבטחה (למשל, אבטחה תוסף ESLint, Bandit עבור Python) יכול לתפוס בעיות במהלך סקירת קוד לפני שהם מגיעים הייצור.

בדיקה אוטומטית ב- CI/CD

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

איומים על מודל

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

הקמת תוכנית גילוי Vulnerability

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

מסקנה

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

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