Forwarded from HICTE Blog (smm)
#امنیت
[بخش یکم]
ToCToU
یا Time of Check to Time of Use نوعی آسیب پذیری امنیتی هست و وقتی ایجاد میشه که بین چک کردن یه شرایط و استفاده از اون از نظر زمانی gap بوجود بیاد.
مثلا اگه یه برنامه بررسی کنه آیا کاربر مجوز دسترسی به یه فایل رو داره یا نه و بعدا از اون فایل استفاده کنه تو این شرایط به طور بالقوه یه مهاجم ممکنه فایل یا مجوزهای اون رو بین بررسی و استفاده تغییر بده و منجر به یه نقض امنیتی بشه.
برای دوری از این آسیب پذیری توسعه دهنده باید از استراتژیهایی استفاده کنه تا این اطمینان حاصل بشه که وضعیت بررسی شده در طول فاصله زمانی تا نقطهی استفاده بدون تغییر باقی میمونه.
لینک به بخش دوم
🚁 Hicte Blog
[بخش یکم]
ToCToU
یا Time of Check to Time of Use نوعی آسیب پذیری امنیتی هست و وقتی ایجاد میشه که بین چک کردن یه شرایط و استفاده از اون از نظر زمانی gap بوجود بیاد.
مثلا اگه یه برنامه بررسی کنه آیا کاربر مجوز دسترسی به یه فایل رو داره یا نه و بعدا از اون فایل استفاده کنه تو این شرایط به طور بالقوه یه مهاجم ممکنه فایل یا مجوزهای اون رو بین بررسی و استفاده تغییر بده و منجر به یه نقض امنیتی بشه.
برای دوری از این آسیب پذیری توسعه دهنده باید از استراتژیهایی استفاده کنه تا این اطمینان حاصل بشه که وضعیت بررسی شده در طول فاصله زمانی تا نقطهی استفاده بدون تغییر باقی میمونه.
لینک به بخش دوم
🚁 Hicte Blog
Forwarded from HICTE Blog (smm)
HICTE Blog
#امنیت [بخش یکم] ToCToU یا Time of Check to Time of Use نوعی آسیب پذیری امنیتی هست و وقتی ایجاد میشه که بین چک کردن یه شرایط و استفاده از اون از نظر زمانی gap بوجود بیاد. مثلا اگه یه برنامه بررسی کنه آیا کاربر مجوز دسترسی به یه فایل رو داره یا نه و بعدا…
#امنیت
[بخش دوم]
ToCToU
برای مثال یه سناریوی ساده رو در نظر میگیریم:
ما یه تابع پایتون داریم که hash یه فایل رو چک میکنه و اگه فایل درست وجود داشت بعد محتوای اون رو بر میگردونه.
اینجا مهاجم میتونه با تغییر فایل اصلی تو فاصله زمانی بین چک کردن hash و باز کردن فایل به اهداف شومش برسه.
برای اینکه کار دست خودمون ندیم بعد باز کردن اون از محتوای فایل hash میگیریم.
لینک به بخش یکم
🚁 Hicte Blog
[بخش دوم]
ToCToU
برای مثال یه سناریوی ساده رو در نظر میگیریم:
ما یه تابع پایتون داریم که hash یه فایل رو چک میکنه و اگه فایل درست وجود داشت بعد محتوای اون رو بر میگردونه.
import os
def read_file(file_path):
# Time of Check: Check if the right file exists
if os.path.exists(file_path) and hash_check(file_path):
# Time of Use: Open and read the file
with open(file_path, 'r') as file:
content = file.read()
return content
else:
print("File does not exist.")
اینجا مهاجم میتونه با تغییر فایل اصلی تو فاصله زمانی بین چک کردن hash و باز کردن فایل به اهداف شومش برسه.
# Create a malicious file
echo "Malicious content" > sensitive_file.txt
برای اینکه کار دست خودمون ندیم بعد باز کردن اون از محتوای فایل hash میگیریم.
import os
def read_file(file_path):
if os.path.exists(file_path):
with open(file_path, 'r') as file:
content = file.read()
# Content state locked from outside
if hash_check(content):
return content
else:
print("File does not exist.")
لینک به بخش یکم
🚁 Hicte Blog
Forwarded from Linuxor ?
Forwarded from Webinarfarsi | Soheib Kiani | وبینار فارسی
Media is too big
VIEW IN TELEGRAM
دیدنش میتونه به شما کمک کنه
Forwarded from Webinarfarsi | Soheib Kiani | وبینار فارسی
نکته خوب از زبان برنامه نویس اسبق گوگل در مورد refactoring
https://www.linkedin.com/posts/dryuan_cleancode-refactoring-technicaldebt-activity-7316136240469155840-mQic?utm_source=share&utm_medium=member_android&rcm=ACoAAD0lsT0BtYSF42wgWR-cYqcAiCrCBgM5hJc
https://www.linkedin.com/posts/dryuan_cleancode-refactoring-technicaldebt-activity-7316136240469155840-mQic?utm_source=share&utm_medium=member_android&rcm=ACoAAD0lsT0BtYSF42wgWR-cYqcAiCrCBgM5hJc
Linkedin
Refactoring code: risks and considerations | Feng Yuan posted on the topic | LinkedIn
It seems I have different options on lots of stuff, including cleaning/refactoring code.
If you have your own code base, clean as much as often as you want. You take all the risk/glory.
But if you're working on a big critical piece of software, be very…
If you have your own code base, clean as much as often as you want. You take all the risk/glory.
But if you're working on a big critical piece of software, be very…
Forwarded from Webinarfarsi | Soheib Kiani | وبینار فارسی
🚩 10 Red flags of a Software Engineer:
1) Always says “it works on my machine”
2) Doesn’t care about the product’s users or their needs
3) Never mentors or shares knowledge
4) Can’t explain what they’re doing to anyone non-technical
5) Blames PMs, design, QA, and “legacy code” for everything
6) Doesn't test their code properly (QA should do it)
7) Consistently misestimates tasks
8) Avoids documentation: "The code is self-documenting"
9) Declares "it's impossible", instead of suggesting ways to solve challenges
10)Freaks out under the pressure
1) Always says “it works on my machine”
2) Doesn’t care about the product’s users or their needs
3) Never mentors or shares knowledge
4) Can’t explain what they’re doing to anyone non-technical
5) Blames PMs, design, QA, and “legacy code” for everything
6) Doesn't test their code properly (QA should do it)
7) Consistently misestimates tasks
8) Avoids documentation: "The code is self-documenting"
9) Declares "it's impossible", instead of suggesting ways to solve challenges
10)Freaks out under the pressure
Forwarded from ZGP
جایگزین ifconfig در لینوکس
nmcli -p device show
ip -c a
nmcli -p device show
ip -c a
❤2