اشتراکها
CSRF یا Cross Site Request Forgery به صورت خلاصه به این معنا است که شخص مهاجم اعمالی را توسط شما و با سطح دسترسی شما بر روی سایت انجام دهد و اطلاعات مورد نظر خود را استخراج کرده (محتویات کوکی یا سشن و امثال آن) و به هر سایتی که تمایل دارد ارسال کند. اینکار عموما با تزریق کد در صفحه صورت میگیرد. مثلا ارسال تصویری پویا به شکل زیر در یک صفحه فوروم، بلاگ یا ایمیل:
<img src="http://www.example.com/logout.aspx">
شخصی که این صفحه را مشاهده میکند، متوجه وجود هیچگونه مشکلی نخواهد شد و مرورگر حداکثر جای خالی تصویر را به او نمایش میدهد. اما کدی با سطح دسترسی شخص بازدید کننده بر روی سایت اجرا خواهد شد.
روشهای مقابله:
- هر زمانیکه کار شما با یک سایت حساس به پایان رسید، log off کنید. به این صورت بجای منتظر شدن جهت به پایان رسیدن خودکار طول سشن، سشن را زودتر خاتمه دادهاید یا برنامه نویسها نیز باید طول مدت مجاز سشن در برنامههای حساس را کاهش دهند. شاید بپرسید این مورد چه اهمیتی دارد؟ مرورگری که امکان اجازهی بازکردن چندین سایت با هم را به شما در tab های مختلف میدهد، ممکن است سشن یک سایت را در برگهای دیگر به سایت مهاجم ارسال کند. بنابراین زمانیکه به یک سایت حساس لاگین کردهاید، سایتهای دیگر را مرور نکنید. البته مرورگرهای جدید مقاوم به این مسایل شدهاند ولی جانب احتیاط را باید رعایت کرد.
- در برنامه خود قسمت Referrer header را بررسی کنید. آیا متد POST رسیده، از سایت شما صادر شده است یا اینکه صفحهای دیگر در سایتی دیگر جعل شده و به برنامه شما ارسال شده است؟ هر چند این روش آنچنان قوی نیست و فایروالهای جدید یا حتی بعضی از مرورگرها با افزونههایی ویژه، امکان عدم ارسال این قسمت از header درخواست را میسر میسازند.
- برنامه نویسها نباید مقادیر حساس را از طریق GET requests ارسال کنند. استفاده از روش POST نیز به تنهایی کارآمد نیست و آنرا باید با random tokens ترکیب کرد تا امکان جعل درخواست منتفی شود. برای مثال استفاده از ViewStateUserKey در ASP.Net . جهت خودکار سازی اعمال این موارد در ASP.Net، اخیرا HTTP ماژول زیر ارائه شده است:
تنها کافی است که فایل dll آن در دایرکتوری bin پروژه شما قرار گیرد و در وب کانفیگ برنامه ارجاعی به این ماژول را لحاظ نمائید.
کاری که این نوع ماژولها انجام میدهند افزودن نشانههایی اتفاقی ( random tokens ) به صفحه است که مرورگر آنها را بخاطر نمیسپارد و این token به ازای هر سشن و صفحه منحصر بفرد خواهد بود.
برای PHP نیز چنین تلاشهایی صورت گرفته است:
http://csrf.htmlpurifier.org/
مراجعی برای مطالعه بیشتر
Prevent Cross-Site Request Forgery (CSRF) using ASP.NET MVC’s AntiForgeryToken() helper
Cross-site request forgery
Top 10 2007-Cross Site Request Forgery
CSRF - An underestimated attack method
نظرات مطالب
معماری لایه بندی نرم افزار #3
محسن عزیز. از شما ممنونم که به نکتههای ظریفی اشاره کردید.
در سری مقالات اولیه فقط دارم یک دید کلی به کسایی میدم که تازه دارن با این مفاهیم آشنا میشن. این پروژه اولیه دستخوش تغییرات زیادی میشه. در واقع محصول نهایی این مجموعه مقالات بر پایه همین نوع لایه بندی ولی بادید و طراحی مناسبتر خواهد بود.
در مورد ORM هم من با چند Application سروکار داشتم که در روال توسعه بخشهای جدید رو بنا به دلایلی با ORM یا DB متفاوتی توسعه داده اند. غیر از این موضوع، حتی بخشهایی از مدل، سرویس و یا مخزن رو در پروژههای دیگری استفاده کرده اند. همچنین برخی از نکات مربوط به تفکیک لایهها به منظور تست پذیری راحتتر رو هم در نظر بگیرید.
در مورد اشیا Request و Response هم باید خدمتتان عرض کنم که برای درخواست و پاسخ به درخواست استفاده میشوند که چون پروژه ای که مثال زدم کوچک بوده ممکنه کاملا درکش نکرده باشید. ما کلاسهای Request و Response متعددی در پروژه داریم که ممکنه خیلی از اونها فقط از یک View Model استفاده کنن ولی پارامترهای ارسالی یا دریافتی آنها متفاوت باشد.
در مورد try...catch هم من با شما کاملا موافقم. به دلیل هزینه ای که دارد باید در آخرین سطح قرار بگیرد. در این مورد ما میتونیم اونو به Presentation و یا در MVC به Controller منتقل کنیم.
در مورد DbContext هم هنوز الگویی رو معرفی نکردم. در واقع هنوز وارد جزئیات لایهی Data نشدم. در مورد اون اگه اجازه بدی بعدا صحبت میکنم.
اشتراکها
معرفی WebHook ها
WebHooks is a lightweight HTTP pattern providing a simple pub/sub model for wiring together Web APIs and SaaS services. When an event happens in a service, a notification is sent in the form of an HTTP POST request to registered subscribers. The POST request contains information about the event which makes it possible for the receiver to act accordingly Introducing Microsoft ASP.NET WebHooks PreviewSending WebHooks with ASP.NET WebHooks Preview ASP.NET WebHooks Documentation
Introducing Microsoft ASP.NET WebHooks Preview
ASP.NET WebHooks Documentation
Introducing Microsoft ASP.NET WebHooks Preview
ASP.NET WebHooks Documentation
چندی قبل مطلب «اطلاع از بروز رسانی نرم افزار ساخته شده» را در سایت جاری مطالعه کردید. در این روش بسیار متداول، شماره نگارشهای جدید برنامه در یک فایل XML و مانند آن قرار میگیرند و برنامه هربار این فایل را جهت یافتن شمارههای مندرج در آن اسکن میکند. اگر پروژهی شما سورس باز است و در GitHub هاست شده، روش دیگری نیز برای یافتن این اطلاعات وجود دارد. در GitHub میتوان از طریق آدرسی به شکل https://api.github.com/repos/user_name/project_name/releases به اطلاعات آخرین ارائههای یک پروژه (قرار گرفته در برگهی releases آن) با فرمت JSON دسترسی یافت (یک مثال). در ادامه قصد داریم روش استفادهی از آنرا بررسی کنیم.
ساختار JSON ارائههای یک پروژه در GitHub
ساختار کلی اطلاعات ارائههای یک پروژه در GitHub چنین شکلی را دارد:
در اینجا آرایهای از اطلاعات ارائهی یک پروژه ارسال میشود. هر ارائه نیز دارای دو قسمت است: لینکی به صفحهی اصلی release در GitHub و سپس آرایهای به نام assets که در آن اطلاعات فایلهای پیوستی مانند نام فایل، آدرس، اندازه و امثال آن قرار گرفتهاند.
تهیهی کلاسهای معادل فرمت JSON ارائههای برنامه در GitHub
اگر بخواهیم قسمتهای مهم خروجی JSON فوق را تبدیل به کلاسهای معادل دات نتی کنیم، به دو کلاس ذیل خواهیم رسید:
در اینجا از ویژگی JsonProperty جهت معرفی نامهای واقعی خواص ارائه شدهی توسط GitHub استفاده کردهایم.
پس از تشکیل این کلاسها، مرحلهی بعد، دریافت اطلاعات JSON از آدرس API ارائههای پروژه در GitHub و سپس نگاشت آنها میباشد:
حین کار با WebClient یا هر روش دیگری که برای دریافت اطلاعات از وب استفاده میکنید، حتما نیاز است user-agent را ذکر کرد. در غیر اینصورت GitHub درخواست شما را برگشت خواهد زد. پس از دریافت اطلاعات JSON، با استفاده از متد JsonConvert.DeserializeObject کتابخانهی JSON.NET، میتوان آنها را تبدیل به آرایهای از GitHubProjectRelease کرد.
یک نکته: اگر به صفحهی اصلی ارائههای یک پروژه در GitHub دقت کنید، شمارهی تعداد بار دریافت یک ارائه مشخص نشدهاست. در این API، عدد DownloadCount، بیانگر تعداد بار دریافت پروژهی شما است.
ساختار JSON ارائههای یک پروژه در GitHub
ساختار کلی اطلاعات ارائههای یک پروژه در GitHub چنین شکلی را دارد:
[ { release_info, "assets": [ { } ] } ]
تهیهی کلاسهای معادل فرمت JSON ارائههای برنامه در GitHub
اگر بخواهیم قسمتهای مهم خروجی JSON فوق را تبدیل به کلاسهای معادل دات نتی کنیم، به دو کلاس ذیل خواهیم رسید:
using Newtonsoft.Json; using System; namespace ApplicationAnnouncements { public class GitHubProjectRelease { [JsonProperty(PropertyName = "url")] public string Url { get; set; } [JsonProperty(PropertyName = "assets_url")] public string AssetsUrl { get; set; } [JsonProperty(PropertyName = "upload_url")] public string UploadUrl { get; set; } [JsonProperty(PropertyName = "html_url")] public string HtmlUrl { get; set; } [JsonProperty(PropertyName = "id")] public int Id { get; set; } [JsonProperty(PropertyName = "tag_name")] public string TagName { get; set; } [JsonProperty(PropertyName = "target_commitish")] public string TargetCommitish { get; set; } [JsonProperty(PropertyName = "name")] public string Name { get; set; } [JsonProperty(PropertyName = "body")] public string Body { get; set; } [JsonProperty(PropertyName = "draft")] public bool Draft { get; set; } [JsonProperty(PropertyName = "prerelease")] public bool PreRelease { get; set; } [JsonProperty(PropertyName = "created_at")] public DateTime CreatedAt { get; set; } [JsonProperty(PropertyName = "published_at")] public DateTime PublishedAt { get; set; } [JsonProperty(PropertyName = "assets")] public Asset[] Assets { get; set; } } public class Asset { [JsonProperty(PropertyName = "url")] public string Url { get; set; } [JsonProperty(PropertyName = "id")] public int Id { get; set; } [JsonProperty(PropertyName = "name")] public string Name { get; set; } [JsonProperty(PropertyName = "label")] public string Label { get; set; } [JsonProperty(PropertyName = "content_type")] public string ContentType { get; set; } [JsonProperty(PropertyName = "state")] public string State { get; set; } [JsonProperty(PropertyName = "size")] public int Size { get; set; } [JsonProperty(PropertyName = "download_count")] public int DownloadCount { get; set; } [JsonProperty(PropertyName = "created_at")] public DateTime CreatedAt { get; set; } [JsonProperty(PropertyName = "updated_at")] public DateTime UpdatedAt { get; set; } } }
پس از تشکیل این کلاسها، مرحلهی بعد، دریافت اطلاعات JSON از آدرس API ارائههای پروژه در GitHub و سپس نگاشت آنها میباشد:
using (var webClient = new WebClient()) { webClient.Headers.Add("user-agent", "DNTProfiler"); var jsonData = webClient.DownloadString(url); var gitHubProjectReleases = JsonConvert.DeserializeObject<GitHubProjectRelease[]>(jsonData); foreach (var release in gitHubProjectReleases) { foreach (var asset in release.Assets) { // … } } }
یک نکته: اگر به صفحهی اصلی ارائههای یک پروژه در GitHub دقت کنید، شمارهی تعداد بار دریافت یک ارائه مشخص نشدهاست. در این API، عدد DownloadCount، بیانگر تعداد بار دریافت پروژهی شما است.
نظرات اشتراکها
افزایش پرفورمنسAPI با استفاده از FastEndpoints
نظر شخصی من اینه که از آمار github و nuget پروژه میشه متوجه شد که پروژه در سطح قابل قبولی هست.
اشتراکها
نمودارهای مدرن و متن باز SVG
GitHub-inspired modern, intuitive and responsive charts with zero dependencies
اشتراکها
20 مخزن کد مفید برای توسعه دهندهها
اشتراکها