none
עבודה עם ספריות JSON ב CLR RRS feed

  • שאלה

  • שלום רב!


    אני רוצה להתחיל פרוייקט NET ב CLR (עבורי זה חדש ומאתגר)

    למרבה האבסורד, אחת הבעיות שניתקלתי בהן שספריות מקובלות לטיפול בסוג אובייקט JSON  כמו של newtonsoft או אפילו של מיקרוסופט אינן נתמכות ב CLR

    אלא אם מתקינים אותן בצורה פחות מאובטחת (להבנתי)

    למשל כאן -יש הסבר אחד מיני רבים

    https://stackoverflow.com/questions/42175673/how-to-use-json-parser-in-clr-procedure

    השאלה שלי היא:

    האם דרך ההתקנה המוצעתשם בעיקר PERMISSION_SET = UNSAFE היא ממולצת או לא,

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

    תודה

    שני




    שבת 25 ספטמבר 2021 12:25

תשובות

  • כמה נקודות קשורות חשובות :

    > אחת המגבלות לצערי שקיימות היא שלא ניתן לפתח בקוד C# תחת SQL כאמור, בשיתוף סיפריות כדוגמת זו שהבאת

    1. יש רק כמה ספריות בודדות אשר ניתן לעבוד איתן ישירות מכיוון שהן מוגדרות כנתמכות (נבדקות כנראה על ידי צמוות ה SQL ואושרו בצורה קשיחה בשרת)

    https://docs.microsoft.com/en-us/sql/relational-databases/clr-integration/database-objects/supported-net-framework-libraries?redirectedfrom=MSDN#supported-libraries

    2. אישית אני לא עובד עם הספרייה של System.Text.Json

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

    אני עובד הרבה עם CLR וגם בגרסת 2019 למרות התמיכה ב JSON שיש כבר מ 2016, יש דברים שאני מעדיף את הקוד שלי איתו אני עובד מ 2005 כבר. אני עובד בעיקר עם ספריית Newtonsoft.Json

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

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

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

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

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



    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]

    • סומן כתשובה על-ידי Pixel2000 יום שני 04 אוקטובר 2021 18:06
    יום ראשון 03 אוקטובר 2021 13:32
    מנחה דיון

כל התגובות

  • שלום שני וברוך/ברוכה הבא/ה לפורומים של מיקרוסופט

    > אני רוצה להתחיל פרוייקט NET ב CLR (עבורי זה חדש ומאתגר)

    לךהבהרה כדי שנדע להיכן מתקדמים,

    אתה נמצא בפורום של שרתי SQL ולא בפורום .Net 

    האם אתה מתכוון לפרוייקט של SQLCLR ז"א שימוש ב CLR בשרתי SQL? 

    * הערה: מכיוון שאנחנו נמצאים בפורום של שרתי SQL אז כדאי לציין ששרתי SQL כוללים בצורה מובנית תמיכה מלאה בטקסט בפורמט JSON.

    > אינן נתמכות ב CLR

    למה הכוונה שהספריות אינן נתמכות ב CLR? האם אתה יודע מה זה CLR?

    כל הספריות של כל השפות בטכנולוגיית .Net תומכות ב CLR מכיוון ש CLR היא שפת הביניים של .Net

    הבעיה שלך לא מובנת לי ולא נשמעת הגיונית. כנראה לא מוסברת טוב או שלא הבנת מה זה CLR ומה זה דוט-נט אולי?

    נסה להבהיר ולהרחיב בבקשה למה הכוונה בפרוייקט CLR (האם אתה מפתח קוד ישירות בשפת CLR?)

    להבהרה, למיקרוסגופט יש ספרייה מלאה לשימוש ב JSON. אתה יכול להוריד את הספרייה System.Text.Json ולקרוא מעט יותר בקישור הבא:

    https://docs.microsoft.com/en-us/dotnet/standard/serialization/system-text-json-overview


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]

    יום ראשון 26 ספטמבר 2021 22:10
    מנחה דיון
  • הי רונן

    תודה על המענה המהיר. 

    אכן SQLCLR - CLR תחת SQL SERVER היא אפשרות לכתוב קוד C# בתוך SQL SERVER (תחת מגבלות מסוימות) 

    אנא ראה כאן 

    https://docs.microsoft.com/en-us/sql/relational-databases/clr-integration/common-language-runtime-integration-overview?view=sql-server-ver15

    ניתן לכתוב פרוצדורות, פונקציות ולבנות מחלקות תחת SQL SERVER שזה יתרון לא רע משום שהוא מרחיב את שפת T-SQL

    אחת המגבלות לצערי שקיימות היא שלא ניתן לפתח בקוד C# תחת SQL כאמור, בשיתוף סיפריות כדוגמת זו שהבאת- אלא אם מגדירים את מסד הנתונים PERMISSION_SET = UNSAFE 

    אם תסתכל בקישור שהבאתי- יש שם דיון שלם על זה. 

    השאלה שלי היא על המחיר - מה המשמעות של הפיכת PERMISSION_SET = UNSAFE

    • נערך על-ידי Pixel2000 יום רביעי 29 ספטמבר 2021 07:30 עריכה
    • נערך על-ידי pituachMVP, Moderator יום ראשון 03 אוקטובר 2021 00:28 ניקוי פורמט של הטקסט
    יום רביעי 29 ספטמבר 2021 07:26
  • אהלן :-) 

    > השאלה שלי היא על המחיר - מה המשמעות של הפיכת PERMISSION_SET = UNSAFE

    זה שאלה טובה אבל קצת קשה לענות עליה במדוייק מכיוון שזה דיי תלוי במה שאתה עושה בקוד של ה CLR

    המאפיין PERMISSION_SET קובע את ההרשאות של קוד ה CLR שלנו לגבי הגישה לשימוש במשאבים/כלים מחוץ למסד הנתונים של השרת. השימוש בברירת המחדל SAFE הוא הקשוח ביותר וקובע שאין לקוד שלנו שום גישה חיצונית. השימוש ברמה של EXTERNAL_ACCESS היא אפשרות הביניים ולפני שקופצים לפתוח את כל הדלתות כדאי לחשוב על שימוש באפשרות הזו אם צריכים גישה למשאבים מחוץ לשרת. אפשרות מאפשר למשל את הגישה לקבצים במערכת ההפעלה, לרשת האינטרנט/אינטראנט ואפילו לפרמטרים ברמת מערכת ההפעלה או registry. זה דיי נראה לי דיי פתוח

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

    Managed code is not compiled to machine code but to an intermediate language which is interpreted and executed by some service operating within  secure framework which mean it has some security of the framework. Unmanaged code is compiled to machine code and therefore executed by the OS directly and can impact the OS directly without any security wrapping level.

    נשמע מסוכן?!?

    לא כל כך, וזה הטעות הכי נפוצה!

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

    אז מתי מתחילה הבעיה?

    כאשר הקוד עצמו לא בטוח. אם למשל ב CLR שלך אתה עושה שימוש ב dll שקיבלת ממישהו אחר ואתה לא יודע מה הוא עושה ואתה עובד על הרשאה SAFE אז מקסימום הקוד שיצרת יכול ליצור נזק ברמת מסדי הנתונים, אבל אם עשית שימוש ב UNSAFE והקוד שלך בלי לדעת כולל פניה ל registry של מערכת ההפעלה אז הוא יוכל למחוק שם ערכים ולעשות כל דבר.

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

    חשוב מאוד! בגרסת 2017 ומאוחר יותר, בברירת המחדל אין בכלל משמעות להגדרה שלך לערך של ה PERMISSION_SET בזמן השימוש בקוד. מגרסת 2017 בברירת המחדל תמיד הקוד מקומפל במצב UNSAFE

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

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

    > https://docs.microsoft.com/en-us/sql/relational-databases/clr-integration/common-language-runtime-integration-overview?view=sql-server-ver15

    Microsoft recommends that all assemblies be signed by a certificate or asymmetric key with a corresponding login that has been granted UNSAFE ASSEMBLY permission in the master database.

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

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

    אני מקווה שזה מבהיר את העיניין :-)


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]

    יום ראשון 03 אוקטובר 2021 13:16
    מנחה דיון
  • כמה נקודות קשורות חשובות :

    > אחת המגבלות לצערי שקיימות היא שלא ניתן לפתח בקוד C# תחת SQL כאמור, בשיתוף סיפריות כדוגמת זו שהבאת

    1. יש רק כמה ספריות בודדות אשר ניתן לעבוד איתן ישירות מכיוון שהן מוגדרות כנתמכות (נבדקות כנראה על ידי צמוות ה SQL ואושרו בצורה קשיחה בשרת)

    https://docs.microsoft.com/en-us/sql/relational-databases/clr-integration/database-objects/supported-net-framework-libraries?redirectedfrom=MSDN#supported-libraries

    2. אישית אני לא עובד עם הספרייה של System.Text.Json

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

    אני עובד הרבה עם CLR וגם בגרסת 2019 למרות התמיכה ב JSON שיש כבר מ 2016, יש דברים שאני מעדיף את הקוד שלי איתו אני עובד מ 2005 כבר. אני עובד בעיקר עם ספריית Newtonsoft.Json

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

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

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

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

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



    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]

    • סומן כתשובה על-ידי Pixel2000 יום שני 04 אוקטובר 2021 18:06
    יום ראשון 03 אוקטובר 2021 13:32
    מנחה דיון
  • אני ממש מודה לך על התשובה המפורטת והמחכימה

    אחרי תשובה כזו אפשר לראות שיש לי עוד הרבההההההה ללמוד!

    תודה רבה!

    יום שני 04 אוקטובר 2021 18:07
  • הכיף :-) 

    לכולנו יש עוד מה ללמוד תמיד

    שמח שיכולתי לעזור מעט


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]

    יום חמישי 07 אוקטובר 2021 01:04
    מנחה דיון