Custom Technical Assessments for Engineering Candidates
یک نکتهی تکمیلی: چگونه یک مخزن Fork شدهی Git را به روز رسانی کنیم؟
اگر پس از مدتی، مجددا نیاز به کار با مخزن Fork شدهی خود را داشته باشید، احتمالا این مخزن هم اکنون دیگر با مخزن اصلی که از آن Fork شده، هماهنگ نیست و قدیمی شدهاست. به همین جهت نیاز است در مخزن محلی خود (Clone ایی که از این Fork بر روی سیستم خود دارید)، این دستورات را صادر کنید تا هم این مخزن محلی و هم مخزن راه دور GitHub شما، هر دو با مخزن اصلی هماهنگ شوند:
در این دستورات https://github.com/user/project_name.git به آدرس مخزن اصلی که از آن Fork را تهیه کردهاید، اشاره میکند.
اگر پس از مدتی، مجددا نیاز به کار با مخزن Fork شدهی خود را داشته باشید، احتمالا این مخزن هم اکنون دیگر با مخزن اصلی که از آن Fork شده، هماهنگ نیست و قدیمی شدهاست. به همین جهت نیاز است در مخزن محلی خود (Clone ایی که از این Fork بر روی سیستم خود دارید)، این دستورات را صادر کنید تا هم این مخزن محلی و هم مخزن راه دور GitHub شما، هر دو با مخزن اصلی هماهنگ شوند:
git remote add upstream https://github.com/user/project_name.git git pull upstream master git push -f origin master
اشتراکها
چه نیازی به https داریم ؟
روشی بهتر برای مدیریت محتوای مخلوط (لینک به HTTP و HTTPS در یک صفحه) در مرورگرهای جدید
در مورد محتوای مخلوط و «اصلاح تمام آدرسهایی که پیشتر توسط برنامه تولید شدهاند» در مطلب فوق نکتهای عنوان شدهاست. روش دیگر مدیریت آن که نیازی به اصلاح محتوای صفحات سایت را ندارد، استفاده از هدر امنیتی «Content-Security-Policy: upgrade-insecure-requests» است:
کار این هدر ویژه ، ارتقاء خودکار لینکهای درج شدهی در صفحات به نگارشهای HTTPS آنها است. برای مثال این تصویری است که پیش از اعمال این هدر جهت درخواست آدرس gravatar یک کاربر ارسال شدهاست و اخطار محتوای مخلوط را میدهد:
و این تصویری است که پس از اعمال هدر upgrade-insecure-requests قابل مشاهدهاست که دیگر اخطار محتوای مخلوط را به همراه ندارد:
در مورد محتوای مخلوط و «اصلاح تمام آدرسهایی که پیشتر توسط برنامه تولید شدهاند» در مطلب فوق نکتهای عنوان شدهاست. روش دیگر مدیریت آن که نیازی به اصلاح محتوای صفحات سایت را ندارد، استفاده از هدر امنیتی «Content-Security-Policy: upgrade-insecure-requests» است:
<system.webServer> <httpProtocol> <customHeaders> <add name="Strict-Transport-Security" value="max-age=16070400; includeSubDomains" /> <add name="Content-Security-Policy" value="upgrade-insecure-requests;" /> </customHeaders> </httpProtocol>
و این تصویری است که پس از اعمال هدر upgrade-insecure-requests قابل مشاهدهاست که دیگر اخطار محتوای مخلوط را به همراه ندارد:
نظرات اشتراکها
NET Core 3. و پشتیبانی از Windows Desktop Applications
همانطور که در تصویر مشخصه، پشتیبانی از Windows Applications به صورت Windows Desktop Packs و فقط مختص به سیستمعامل ویندوز است:
‘Support for Windows desktop will be added as a set of “Windows Desktop Packs”, which will only work on Windows. .NET Core isn’t changing architecturally with this new version. We’ll continue to offer a great cross-platform product, focused on the cloud.’
مرورگرهای جدید تحت زیر مجموعهای به نام Content Security Policy، قابلیتهای توکاری را اضافه کردهاند تا حملاتی مانند XSS را حتی در برنامهی وبی که برای این نوع حملات تمهیداتی را درنظر نگرفتهاست، خنثی کنند. این قابلیتها به صورت پیش فرض فعال نبوده و نیاز است برنامه نویس صراحتا درخواست فعال شدن آنها را از طریق افزودن تعدادی هدر مشخص به Response، ارائه دهد. در ادامه این هدرها را بررسی خواهیم کرد.
غیرفعال کردن اجرای اسکریپتهای inline
عمدهی حملات XSS زمانی قابلیت اجرا پیدا میکنند که مهاجم بتواند به طریقی (ورودیهای اعتبارسنجی نشده)، اسکریپتی را به درون صفحهی جاری تزریق کند. بنابراین اگر ما به مرورگر اعلام کنیم که دیگر اسکریپتهای inline را پردازش نکن، سایت را تا حد زیادی در مقابل حملات XSS مقاوم کردهایم. این قابلیت به صورت پیش فرض خاموش است؛ چون به طور قطع فعال سازی آن بسیاری از سایتهایی را که عادت کردهاند اسکریپتهای خود را داخل صفحات وب مدفون کنند، از کار میاندازد. این نوع سایتها باید به روز شده و اسکریپتها را از طریق فایلهای خارجی js، به سایت و صفحات خود الحاق کنند.
برای فعال سازی این قابلیت، فقط کافی است هدرهای زیر به Response اضافه شوند:
سطر اول به زودی تبدیل به یک استاندارد W3 خواهد شد؛ اما فعلا فقط توسط کروم 25 به بعد پشتیبانی میشود. سطر دوم توسط مرورگرهایی که از موتور WebKit استفاده میکنند، پشتیبانی میشود و سطر سوم مخصوص فایرفاکس است و IE 10 به بعد.
بعد از فعال شدن این قابلیت، فقط اسکریپتهایی که از طریق دومین شما به صفحه الحاق شدهاند، قابلیت اجرا را خواهند یافت و کلیه اسکریپتهای مدفون شده داخل صفحات، دیگر اجرا نخواهد شد. در این حالت اگر از CDN برای الحاق اسکریپتی استفاده میکنید، مثلا مانند الحاق jQuery به صفحه، نیاز است مسیر آنرا صراحتا در این هدر ذکر کنید:
علاوه بر آن حتی میشود پردازش تمام منابع مورد استفاده را نیز مانند تصاویر، شیوهنامهها، فایلهای فلش و غیره، به دومین جاری محدود کرد:
بدیهی است پس از آشنایی با این مورد، احتمالا در پروژههای جدید خود از آن استفاده کنید (چون inline scriptهای فعلی شما را کاملا از کار میاندازد).
نحوهی اضافه کردن هدرهای Content Security Policy به برنامههای ASP.NET
روشی که با هر دو برنامههای وب فرم و MVC کار میکند، تهیه یک HTTP module است؛ به شرح ذیل:
و یا در برنامههای ASP.NET MVC میتوان یک فیلتر جدید را تعریف کرد و سپس آنرا به صورت عمومی معرفی نمود:
در ماژول تهیه شده چند مورد دیگر را نیز مشاهده میکنید:
الف) X-XSS-Protection مربوط است به IE 8 به بعد
ب) تنظیم هدر X-Frame-Options به SameOrigin سبب میشود تا صفحات سایت شما دیگر توسط Iframeها در سایتهای دیگر قابل نمایش نباشد و فقط در سایت جاری بتوان صفحهای را از همان دومین در صورت نیاز توسط Iframeها نمایش داد.
ج) تنظیم X-Content-Type-Options به nosniff سبب میشود تا IE سعی نکند با اجرای یک محتوا سعی در تشخیص mime-type آن کند و به این ترتیب امنیت دسترسی و مشاهده اشیاء قرار گرفته در صفحه (و یا تزریق شده توسط مهاجمین) به شدت بالا خواهد رفت.
برای مطالعه بیشتر
Security through HTTP response headers
پروژهی کاملی مخصوص افزودن هدرهای یاد شده
https://nwebsec.codeplex.com/
یک نکته تکمیلی
توصیه شدهاست تا دیگر از روال رویدادگردان PreSendRequestHeaders برای ارسال هدرها استفاده نکنید؛ چون با پردازشهای غیرهمزمان تداخل ایجاد میکند.
غیرفعال کردن اجرای اسکریپتهای inline
عمدهی حملات XSS زمانی قابلیت اجرا پیدا میکنند که مهاجم بتواند به طریقی (ورودیهای اعتبارسنجی نشده)، اسکریپتی را به درون صفحهی جاری تزریق کند. بنابراین اگر ما به مرورگر اعلام کنیم که دیگر اسکریپتهای inline را پردازش نکن، سایت را تا حد زیادی در مقابل حملات XSS مقاوم کردهایم. این قابلیت به صورت پیش فرض خاموش است؛ چون به طور قطع فعال سازی آن بسیاری از سایتهایی را که عادت کردهاند اسکریپتهای خود را داخل صفحات وب مدفون کنند، از کار میاندازد. این نوع سایتها باید به روز شده و اسکریپتها را از طریق فایلهای خارجی js، به سایت و صفحات خود الحاق کنند.
برای فعال سازی این قابلیت، فقط کافی است هدرهای زیر به Response اضافه شوند:
Content-Security-Policy: script-src 'self' X-WebKit-CSP: script-src 'self' X-Content-Security-Policy: script-src 'self'
بعد از فعال شدن این قابلیت، فقط اسکریپتهایی که از طریق دومین شما به صفحه الحاق شدهاند، قابلیت اجرا را خواهند یافت و کلیه اسکریپتهای مدفون شده داخل صفحات، دیگر اجرا نخواهد شد. در این حالت اگر از CDN برای الحاق اسکریپتی استفاده میکنید، مثلا مانند الحاق jQuery به صفحه، نیاز است مسیر آنرا صراحتا در این هدر ذکر کنید:
Content-Security-Policy: script-src 'self' https://youcdn.com X-WebKit-CSP: script-src 'self' https://yourcdn.com X-Content-Security-Policy: script-src 'self' https://yourcdn.com
Content-Security-Policy: default-src 'self' https://youcdn.com X-WebKit-CSP: default-src 'self' https://yourcdn.com X-Content-Security-Policy: default-src 'self' https://yourcdn.com
نحوهی اضافه کردن هدرهای Content Security Policy به برنامههای ASP.NET
روشی که با هر دو برنامههای وب فرم و MVC کار میکند، تهیه یک HTTP module است؛ به شرح ذیل:
using System; using System.Web; namespace AntiXssHeaders { public class SecurityHeadersConstants { public static readonly string XXssProtectionHeader = "X-XSS-Protection"; public static readonly string XFrameOptionsHeader = "X-Frame-Options"; public static readonly string XWebKitCspHeader = "X-WebKit-CSP"; public static readonly string XContentSecurityPolicyHeader = "X-Content-Security-Policy"; public static readonly string ContentSecurityPolicyHeader = "Content-Security-Policy"; public static readonly string XContentTypeOptionsHeader = "X-Content-Type-Options"; } public class ContentSecurityPolicyModule : IHttpModule { public void Dispose() { } public void Init(HttpApplication app) { app.BeginRequest += AppBeginRequest; } void AppBeginRequest(object sender, EventArgs e) { var app = (HttpApplication)sender; var response = app.Context.Response; setHeaders(response); } private static void setHeaders(HttpResponse response) { response.Headers.Set(SecurityHeadersConstants.XFrameOptionsHeader, "SameOrigin"); // For IE 8+ response.Headers.Set(SecurityHeadersConstants.XXssProtectionHeader, "1; mode=block"); response.Headers.Set(SecurityHeadersConstants.XContentTypeOptionsHeader, "nosniff"); //todo: Add /Home/Report --> public JsonResult Report() { return Json(true); } const string cspValue = "default-src 'self';"; // For Chrome 16+ response.Headers.Set(SecurityHeadersConstants.XWebKitCspHeader, cspValue); // For Firefox 4+ response.Headers.Set(SecurityHeadersConstants.XContentSecurityPolicyHeader, cspValue); response.Headers.Set(SecurityHeadersConstants.ContentSecurityPolicyHeader, cspValue); } } }
//// RegisterGlobalFilters -> filters.Add(new ContentSecurityPolicyFilterAttribute()); public class ContentSecurityPolicyFilterAttribute : ActionFilterAttribute { public override void OnActionExecuting(ActionExecutingContext filterContext) { var response = filterContext.HttpContext.Response; response.AddHeader("Content-Security-Policy", "script-src 'self'"); // the rest ... base.OnActionExecuting(filterContext); } }
الف) X-XSS-Protection مربوط است به IE 8 به بعد
ب) تنظیم هدر X-Frame-Options به SameOrigin سبب میشود تا صفحات سایت شما دیگر توسط Iframeها در سایتهای دیگر قابل نمایش نباشد و فقط در سایت جاری بتوان صفحهای را از همان دومین در صورت نیاز توسط Iframeها نمایش داد.
ج) تنظیم X-Content-Type-Options به nosniff سبب میشود تا IE سعی نکند با اجرای یک محتوا سعی در تشخیص mime-type آن کند و به این ترتیب امنیت دسترسی و مشاهده اشیاء قرار گرفته در صفحه (و یا تزریق شده توسط مهاجمین) به شدت بالا خواهد رفت.
برای مطالعه بیشتر
Security through HTTP response headers
پروژهی کاملی مخصوص افزودن هدرهای یاد شده
https://nwebsec.codeplex.com/
یک نکته تکمیلی
توصیه شدهاست تا دیگر از روال رویدادگردان PreSendRequestHeaders برای ارسال هدرها استفاده نکنید؛ چون با پردازشهای غیرهمزمان تداخل ایجاد میکند.
اشتراکها
Duende IdentityServer v6 منتشر شد
- Performance and stability improvements.
- Optimization and testing for .NET 6.
- All UIs and templates have been updated for “.NET 6” style, which means they now use the new hosting API, and all UIs have been converted to Razor pages.
- Added support for CIBA, which was the last missing piece for full FAPI compliance.
اشتراکها
منبع کدهای MS-DOS در گیت هاب
In March 2014, Microsoft released the source code to MS-DOS 1.25 and 2.0 via the Computer History Museum. The announcement also contains a brief history of how MS-DOS came to be for those new to the subject, and ends with many links to related articles and resources for those interested in learning more.
Today, we're re-open-sourcing MS-DOS on GitHub. Why? Because it's much easier to find, read, and refer to MS-DOS source files if they're in a GitHub repo than in the original downloadable compressed archive file.