Telegram Group & Telegram Channel
Forwarded from Python Hints
وقتی صحبت از امنیت میشه خیلی از توسعه دهنده‌های اینکار رو وظیفه تیم امنیت می‌دونند؛ که خب درست هم هست ولی تا یک جایی. شما هم بعنوان توسعه دهنده باید یک سری موارد رو بدونید.
مثلا خیلی دیدم؛ تیم‌های تست نفوذ فراموش می‌کنند (دسترسی ندارند) الگوریتم hash کردن پسورد داخل دیتابیس رو چک کنند؛ اینجا دانش شما بعنوان برنامه‌نویس پروژه خودش رو نشون میده و یک لایه اطمینان بیشتر برای پروژه خواهد بود.

دمشون گرم؛ تیم توسعه Django رو می‌گم چرا که اکثر اتک‌های مهم رو تا جایی که امکانش هست جلوگیری می‌کنند و برای همین هم همیشه می‌گم بکند رو فارغ از فریمورک یاد بگیرید. با این حال بسیاری دولوپر Django هست که حتی زحمت بررسی و آپدیت به آخرین پچ‌های امنیتی رو به خودش نمیده مثلا pip freeze و version locking استفاده کرده.

توی بعضی مواقع هم دانستن بعضی نکات امنیتی برای optimization بهتون کمک می‌کنه؛ مثلا توی password hash ممکن هست تحت یک شرایط خاصی اصلا الگوریتمی مثل Argon2 به کار شما نیاد و به دلایلی بهش نیاز نداشته باشید تحت این شرایط می‌تونید برگردید روی sha256 و از اون استفاده کنید (این یک مثال بود اگر argon2 رو نمی‌شناسید درموردش بخونید؛ توی لیست PASSWORD_HASHERS های Django هم هست ولی خود Django از PBKDF2 استفاده می‌کنه پیشفرض)


خیلی از برنامه‌نویس‌ها سرویس login امنی دارند که از موارد امنیتی خوبی هم استفاده می‌کنه throttling, brute-force blocker, hashing و ... اما بعضی موارد باید فراتر ازین بره؛ چیزی که خیلی ندیدم حتی روی بعضی سرویس‌های لاگین شرکت‌های بزرگ و موارد حساس.
فرض کنید شما login با ایمیل اعضای شرکت بزنید (ایمیل‌های شرکتی اصول خاصی داره و راحت بدست میاد) اگر ایمیل اشتباه باشه response time شاید زیر 20ms باشه ولی وقتی ایمیل درست هست بالای 100ms می‌شه این یکی از تکنیک‌‌های قدیمی مورد استفاده برای نفوذ به صفحات ادمین بوده و هست. شما وقتی username. email رو پیدا کنی یک نگرانی کمتر خواهی داشت.
برای همین کسی که با این موارد آشنا هست؛ برای اینکه response time لاگین درست و غلط رو یکسان کنه وقتی می‌بینه یوزر وجود نداره بجای اینکه درجا پاسخ رو برای کاربر بفرسته یکبار پسورد رو با یک چیز رندم (طبق validation نمی‌تونه توی دیتابیس باشه) حساب می‌کنه و بعد response اطلاعات غلط روی لاگین رو بر می‌گردونه.


البته که من برای این مثال دست روی یک موردی گذاشتم که خیلی‌ها رعایت نمی‌کنند (شاید نیازی هم ندارند) و خیلی‌ها بلد نیستند (باید دنبال یک جیزی هم می‌گشتم که خود django امن نکرده باشه)

یا مثلا توی کار با دیتا قبول نکردن دیتای pickle؛ اینو برگردید بالا من همون اوایل شروع کار کانال گفتم با مثال و حدود ۶ ماه قبل یکی از خوبای دنیای تکنولوژی با همین روش بهش نفوذ شد (hugging face رو منظورم هست)

یا توی شرکت‌هایی که یوزر فایل آپلود می‌کنه و نیروی انسانی باید فایل رو بررسی کنه؛ خیلی وقتا دیدم فقط پسوند فایل بررسی میشه و ...

حالا چه چیزهایی رو باید بعنوان دولوپر بدونید ؟ OWASP TOP 10 حداقلی ترین مواردی هست که شما بعنوان یک دولوپر باید بشناسید و راهای مقابله باهاش رو هم بلد باشید.

ولی بطور خاص برای Django Rest Framework حداقل این cheathseet رو باید داشته باشد
OWASP cheatsheet for DRF

من یک cheatsheet شخصی خودم دارم (شامل مواردی از بخش‌های مختلف همین cheatsheet هم هست) ولی متاسفانه نمی‌تونم به اشتراک بذارم چون آخرین ورژن رو با داکیومنت شرکت ادغام کردم. اما پیشنهاد میدم لینک بالا رو بخونید و حتما حتما حتما نگاهی هم به رفرنس‌هاشون بندازید این خیلی مهمه.



tg-me.com/djangolearn_ir/1022
Create:
Last Update:

وقتی صحبت از امنیت میشه خیلی از توسعه دهنده‌های اینکار رو وظیفه تیم امنیت می‌دونند؛ که خب درست هم هست ولی تا یک جایی. شما هم بعنوان توسعه دهنده باید یک سری موارد رو بدونید.
مثلا خیلی دیدم؛ تیم‌های تست نفوذ فراموش می‌کنند (دسترسی ندارند) الگوریتم hash کردن پسورد داخل دیتابیس رو چک کنند؛ اینجا دانش شما بعنوان برنامه‌نویس پروژه خودش رو نشون میده و یک لایه اطمینان بیشتر برای پروژه خواهد بود.

دمشون گرم؛ تیم توسعه Django رو می‌گم چرا که اکثر اتک‌های مهم رو تا جایی که امکانش هست جلوگیری می‌کنند و برای همین هم همیشه می‌گم بکند رو فارغ از فریمورک یاد بگیرید. با این حال بسیاری دولوپر Django هست که حتی زحمت بررسی و آپدیت به آخرین پچ‌های امنیتی رو به خودش نمیده مثلا pip freeze و version locking استفاده کرده.

توی بعضی مواقع هم دانستن بعضی نکات امنیتی برای optimization بهتون کمک می‌کنه؛ مثلا توی password hash ممکن هست تحت یک شرایط خاصی اصلا الگوریتمی مثل Argon2 به کار شما نیاد و به دلایلی بهش نیاز نداشته باشید تحت این شرایط می‌تونید برگردید روی sha256 و از اون استفاده کنید (این یک مثال بود اگر argon2 رو نمی‌شناسید درموردش بخونید؛ توی لیست PASSWORD_HASHERS های Django هم هست ولی خود Django از PBKDF2 استفاده می‌کنه پیشفرض)


خیلی از برنامه‌نویس‌ها سرویس login امنی دارند که از موارد امنیتی خوبی هم استفاده می‌کنه throttling, brute-force blocker, hashing و ... اما بعضی موارد باید فراتر ازین بره؛ چیزی که خیلی ندیدم حتی روی بعضی سرویس‌های لاگین شرکت‌های بزرگ و موارد حساس.
فرض کنید شما login با ایمیل اعضای شرکت بزنید (ایمیل‌های شرکتی اصول خاصی داره و راحت بدست میاد) اگر ایمیل اشتباه باشه response time شاید زیر 20ms باشه ولی وقتی ایمیل درست هست بالای 100ms می‌شه این یکی از تکنیک‌‌های قدیمی مورد استفاده برای نفوذ به صفحات ادمین بوده و هست. شما وقتی username. email رو پیدا کنی یک نگرانی کمتر خواهی داشت.
برای همین کسی که با این موارد آشنا هست؛ برای اینکه response time لاگین درست و غلط رو یکسان کنه وقتی می‌بینه یوزر وجود نداره بجای اینکه درجا پاسخ رو برای کاربر بفرسته یکبار پسورد رو با یک چیز رندم (طبق validation نمی‌تونه توی دیتابیس باشه) حساب می‌کنه و بعد response اطلاعات غلط روی لاگین رو بر می‌گردونه.


البته که من برای این مثال دست روی یک موردی گذاشتم که خیلی‌ها رعایت نمی‌کنند (شاید نیازی هم ندارند) و خیلی‌ها بلد نیستند (باید دنبال یک جیزی هم می‌گشتم که خود django امن نکرده باشه)

یا مثلا توی کار با دیتا قبول نکردن دیتای pickle؛ اینو برگردید بالا من همون اوایل شروع کار کانال گفتم با مثال و حدود ۶ ماه قبل یکی از خوبای دنیای تکنولوژی با همین روش بهش نفوذ شد (hugging face رو منظورم هست)

یا توی شرکت‌هایی که یوزر فایل آپلود می‌کنه و نیروی انسانی باید فایل رو بررسی کنه؛ خیلی وقتا دیدم فقط پسوند فایل بررسی میشه و ...

حالا چه چیزهایی رو باید بعنوان دولوپر بدونید ؟ OWASP TOP 10 حداقلی ترین مواردی هست که شما بعنوان یک دولوپر باید بشناسید و راهای مقابله باهاش رو هم بلد باشید.

ولی بطور خاص برای Django Rest Framework حداقل این cheathseet رو باید داشته باشد
OWASP cheatsheet for DRF

من یک cheatsheet شخصی خودم دارم (شامل مواردی از بخش‌های مختلف همین cheatsheet هم هست) ولی متاسفانه نمی‌تونم به اشتراک بذارم چون آخرین ورژن رو با داکیومنت شرکت ادغام کردم. اما پیشنهاد میدم لینک بالا رو بخونید و حتما حتما حتما نگاهی هم به رفرنس‌هاشون بندازید این خیلی مهمه.

BY جنگولرن


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/djangolearn_ir/1022

View MORE
Open in Telegram


telegram Telegram | DID YOU KNOW?

Date: |

Should I buy bitcoin?

“To the extent it is used I fear it’s often for illicit finance. It’s an extremely inefficient way of conducting transactions, and the amount of energy that’s consumed in processing those transactions is staggering,” the former Fed chairwoman said. Yellen’s comments have been cited as a reason for bitcoin’s recent losses. However, Yellen’s assessment of bitcoin as a inefficient medium of exchange is an important point and one that has already been raised in the past by bitcoin bulls. Using a volatile asset in exchange for goods and services makes little sense if the asset can tumble 10% in a day, or surge 80% over the course of a two months as bitcoin has done in 2021, critics argue. To put a finer point on it, over the past 12 months bitcoin has registered 8 corrections, defined as a decline from a recent peak of at least 10% but not more than 20%, and two bear markets, which are defined as falls of 20% or more, according to Dow Jones Market Data.

Telegram Gives Up On Crypto Blockchain Project

Durov said on his Telegram channel today that the two and a half year blockchain and crypto project has been put to sleep. Ironically, after leaving Russia because the government wanted his encryption keys to his social media firm, Durov’s cryptocurrency idea lost steam because of a U.S. court. “The technology we created allowed for an open, free, decentralized exchange of value and ideas. TON had the potential to revolutionize how people store and transfer funds and information,” he wrote on his channel. “Unfortunately, a U.S. court stopped TON from happening.”

telegram from de


Telegram جنگولرن
FROM USA