#MP4 #Video #SQL_Injection
🎥 آموزش تصویری تکنیک بهره بردن از آسیب پذیری تزریق کد SQL به اجرای کد به صورت ریمورت
➖➖➖➖➖
🆔 @PenetrationTest

🍁 كد نويسي نمونه ابزار تست نفوذ آسيب پذيري Sql Injection

در اين ويديو يك ابزار براي نمونه جهت تست آسيب پذيري Sql Injection بر روي وبسايت تحت لينوكس كدنويسي ميكنيم..

🌷 آموزش در پست بعدي قابل دانلود ميباشد
➖➖➖➖➖➖➖➖➖➖
#sql #injection #pentest
Author:4TT4CK3R
🔱 برترين كانال امنيت در ايران
@FullSecurity

#Bug #SQL

📽 آموزش تصویری نفوذ به پنل های جوملا از طریق حفره امنیتی در کامپوننت Tag

نوع باگ : SQL Injection
➖➖➖➖➖➖➖
🎩 @PenetrationTest

#Kali #Hack #SQL

📽 آموزش تصویری ابزار Jsql در کالی لینوکس برای انجام حملات دیتابیس هکینگ
🆔 @PenetrationTest

خب خب خب ORM چیه ؟ 🛸

امروز می‌خوام درباره‌ی یه موضوع مهم و کاربردی تو دنیای برنامه‌نویسی حرف بزنم: ORM یا همون Object-Relational Mapping.

‏🧠 ORM یعنی چی؟

‏ORM (Object-Relational Mapping) یه تکنیک تو برنامه‌نویسیه که داده‌های دیتابیس رو به شکل اشیاء (objects) تو زبون‌های شی‌گرا مثل پایتون، جاوا یا سی‌شارپ مدیریت می‌کنه. به بیان ساده، ORM یه پل ارتباطی بین دنیای شی‌گرایی (کلاس‌ها و اشیاء) و دنیای دیتابیس‌های رابطه‌ای (جداول و ستون‌ها) می‌سازه. با ORM دیگه لازم نیست مستقیم با کوئری‌های SQL کار کنی؛ در عوض، با همون زبون برنامه‌نویسی‌ات دیتابیس رو کنترل می‌کنی.

مثلاً به جای اینکه بنویسی:

SELECT * FROM users

می‌تونی تو پایتون با Django ORM اینجوری بنویسی:

users = User.objects.all()

و همون نتیجه رو بگیری

‏📚 ORM چطوری کار می‌کنه؟
فرض کن تو دیتابیست یه جدول به اسم users داری که ستون‌هاش اینان:

id، name و email

تو برنامه‌ات یه کلاس به اسم User می‌سازی که پراپرتی‌هایی مثل id، name و email داره. ORM این کلاس رو به جدول users توی دیتابیس مپ (map) می‌کنه. یعنی هر شیء از کلاس User نمایانگر یه رکورد تو جدول users می‌شه.

چند تا سناریو رو با هم ببینیم:

1⃣ ذخیره کردن داده:
یه شیء از کلاس User می‌سازی، مقادیرش رو پر می‌کنی و با یه متد مثل save() ذخیره‌اش می‌کنی. ORM این کار رو به یه دستور SQL (مثل INSERT) تبدیل می‌کنه و اجرا می‌کنه.

user = User(name='علی', email='[email protected]')
   user.save()
  

2⃣ خوندن داده:
میتونی به جای کوئری SQL، از متدهایی مثل all() یا filter() استفاده می‌کنی. ORM پشت صحنه کوئری مناسب رو می‌سازه و داده‌ها رو به شکل اشیاء برمی‌گردونه.

   # همه کاربرها
users = User.objects.all()

   # فیلتر کردن
ali_users =
User.objects.filter(name='علی')

به همین سادگی ORM تمام پیچیدگی‌های کار با دیتابیس رو از دید تو مخفی می‌کنه و یه رابط کاربری راحت بهت می‌ده.

البته هر orm با orm های دیگه فرق داره هرچی یه orm بیشتر abstraction انجام داده باشه استفاده ازش راحت تر میشه
ولی توی مقیاس بالاتر همین سادگی باعث پیچیدگی میشه.

‏🚀 ORM برای چی به وجود اومد؟

قبل از اینکه ORMها باشن، برنامه‌نویس‌ها مستقیم با SQL کار می‌کردن. (هرچند همین الانشم توی زبان های هایی که orm مناسبی براش ساخته نشده برنامه نویسان بصورت خام کد sql میزنن مثل برنامه نویسان golang)

این چند تا مشکل داشت و داره:

کدهای طولانی:
برای هر عملیات ساده، باید یه کوئری SQL می‌نوشتی که گاهی خیلی پیچیده می‌شد.

خطای زیاد:
یه اشتباه کوچیک تو کوئری (مثل یه typo) می‌تونست ساعت‌ها وقتت رو تلف کنه.

سختی نگهداری:
اگه ساختار دیتابیست عوض می‌شد (مثلاً یه ستون اضافه یا کم می‌شد)، باید همه کوئری‌ها رو دستی تغییر می‌دادی.

تفاوت پارادایم:
‏ SQL یه زبون declarative (اعلانی) هست، ولی زبون‌هایی مثل پایتون imperative (دستوری) هستن. این یعنی برنامه‌نویس باید مدام بین دو مدل فکری جابه‌جا می‌شد.

‏ORM اومد که این مشکلات رو حل کنه:

سادگی:
کار با دیتابیس مثل کار با اشیاء تو زبون خودت می‌شه.

امنیت:
‏ORMها معمولاً جلوی حملاتی مثل SQL Injection رو می‌گیرن.

انعطاف‌پذیری:
می‌تونی دیتابیس رو عوض کنی (مثلاً از MySQL بری به PostgreSQL) بدون اینکه کل کدت رو تغییر بدی.

سرعت توسعه:
چون کوئری‌نویسی کمتر می‌شه، وقت بیشتری برای منطق اصلی برنامه‌ات داری.

جمع‌بندی ✍
‏ORM یه ابزار باحال و قدرتمنده که کار با دیتابیس رو برای برنامه‌نویس‌ها راحت‌تر، سریع‌تر و امن‌تر می‌کنه. با ORM دیگه لازم نیست با SQL خام کلنجار بری و می‌تونی با همون زبون برنامه‌نویسی‌ات همه‌چیز رو مدیریت کنی.

#️⃣ #database #sql #orm

➖➖➖➖➖➖➖➖➖

🥷 CHANNEL | GROUP

وقتی از دستور "%LIKE "%fo برای جستجو استفاده می‌کنیم، درین شرایط دیتابیس باید تمام اطلاعات رو برامون بررسی کنه که خب باعث میشه سرعت پایین بیاد. راه بهتر برای جستجوی سریعتر استفاده از full-text هستش.

این روش کمک میکنه تا دیتابیس خیلی سریع‌تر و کارآمدتر فرایند جستجو رو انجام بده.
(طریقه استفادش در تصویر درج شده)
#SQL
#PHP
@GoldenCodeir
(به‌منبع و مثالش دقت کنید 👇🏾)
https://x.com/mmartin_joo/status/1902014134561947783?t=jHjPbh6DAmevpRPeQSCDWg&s=35

اگر یک query در دیتابیس کند باشه، می‌تونیم از دستور EXPLAIN استفاده کنیم تا بفهمیم مثلا چطوری یک سرچ یا فیلتر اجرا میشه.
اگه در خروجی EXPLAIN دیدید که 'access type' برابر با ALL هست، یعنی دیتابیس همه‌ی رکوردهای جدول رو داره بررسی میکنه که باعث کندی میشه. درین صورت باید از index استفاده کنیم تا سرعت query بیشتر بشه.

حالا چجوری ازش استفاده کنیم؟

EXPLAIN SELECT * FROM users WHERE age > 30;

#sql
@GoldenCodeir

(به‌منبع دقت کنید 👇🏾)
https://x.com/mmartin_joo/status/1904174361642205309?t=rdYfmiptB7CN_obg0VDafg&s=19

خب حالا بریم سراغ C یا همون Consistency(سازگاری) در ACID:

ویژگی Consistency در دیتابیس یعنی بعد از انجام هر transaction، دیتاهامون باید همیشه صحیح و درست باقی بمونن. یعنی دیتابیس نباید هیچ وقت به وضعیتی نادرست یا اشتباه برسه.

📌 اگه transaction ها قوانین دیتابیس رو رعایت نکنن (مثلاً مقدار موجودی کافی نباشه)، سیستم اونا رو رد میکنه و هیچ تغییری روی داده‌ها اعمال نمیشه.
پس یعنی بعد از هر تغییر در دیتابیس، سیستم باید مطمئن بشه که همه‌چیز درست و منطبق با قوانین دیتابیس هستش.

فرض کنین شما در یک فروشگاه آنلاین قصد خرید یک کالای خاص رو دارید. وقتی وارد سایت میشن و کالای مورد نظر رو به سبد خرید اضافه میکنید، سیستم باید بررسی کنه که آیا موجودی اون کالا کافیه یا نه.
اگه موجودی کالا تموم شده باشه، سیستم اجازه خرید رو به شما نمیده و از انجام تراکنش جلوگیری میکنه.

این نشون دهنده Consistency است که سیستم همیشه دیتاهای صحیح و قابل اعتماد رو حفظ میکنه.👌🏾
#ACID
#SQL
#Database

@GoldenCodeir

نکته مهم برای کوئری‌های MySQL

اگه روی یک ستون دیتابیس ایندکس تعریف شده، استفاده از توابعی مثل YEAR(), MONTH() یا هر تابع دیگه ای روی همون ستون در شرط‌های WHERE باعث میشه MySQL نتونه از ایندکس استفاده کنه.

📌 چرا؟

چون وقتی تابعی روی ستون اعمال میشه، مقدار ستون تغییر میکنه و ایندکس روی مقدار اصلی ستونه، نه مقدار تبدیل‌شده توسط تابع.
در نتیجه MySQL مجبور میشه کل جدول رو اسکن کنه (Full Table Scan) که عملکرد کوئری رو به شدت کاهش میده.

مثال

فرض کنین روی ستون تاریخ paid_at ایندکس دارید و میخواید رکوردهای مربوط به سال 2023 رو بگیرید.

روش اشتباه:

WHERE YEAR(paid_at) = 2023

درین حالت، MySQL برای هر ردیف ابتدا تابع YEAR() رو اجرا میکنه و سپس مقایسه میکنه، که باعث غیرفعال شدن ایندکس میشه.

روش بهینه:

WHERE paid_at >= '2023-01-01' AND paid_at < '2024-01-01'

درین حالت شرط مستقیماً روی ستون paid_at اعمال میشه و MySQL میتونه از ایندکس استفاده کنه، بنابرین کوئری بسیار سریعتر اجرا میشود.
#SQL
#MySql

@GoldenCodeir

(به منبع و مثالش دقت کنید 👇🏾)
https://x.com/mmartin_joo/status/1952704402038333586?s=35

🔵 عنوان مقاله
Observe Live SQL Queries in Go with DTrace

🟢 خلاصه مقاله:
این مطلب از Golang Weekly نشان می‌دهد چطور با استفاده از DTrace بدون تغییر کد و توقف سرویس، کوئری‌های SQL را در برنامه‌های Go به‌صورت زنده مشاهده کنیم. نویسنده با معرفی کوتاهی از DTrace به‌عنوان یک ابزار ردیابی پویا و کم‌سربار، قدم‌به‌قدم نحوه راه‌اندازی روی سیستم‌عامل‌های پشتیبانی‌شده، اتصال به پردازه در حال اجرا و نوشتن اسکریپت‌های ساده برای دیدن متن کوئری، زمان اجرا و الگوهای فراوانی را توضیح می‌دهد؛ همراه با فیلترگذاری برای محدود کردن خروجی به سرویس/کاربر/درایور موردنظر و نکاتی برای حفظ سربار کم.

کاربرد این روش، عیب‌یابی سریع مسائلی مثل کوئری‌های کند، الگوهای N+1، شاخص‌های مفقود و ORM پرحرف در شرایط واقعی تولید است. این رویکرد مکمل لاگ‌ها و APM است و امکان تشخیص فوری و تأیید سریع اصلاحات را می‌دهد. در بخش ملاحظات، به تفاوت پشتیبانی پلتفرم‌ها (مثل FreeBSD و برخی نسخه‌های macOS؛ و پیشنهاد eBPF روی Linux)، نیاز به دسترسی‌های بالا، حساسیت داده‌های متنی کوئری و ضرورت سنجش سربار در محیط staging اشاره می‌شود.

#Go #DTrace #SQL #Observability #Performance #GolangWeekly #eBPF #Database

🟣لینک مقاله:
https://golangweekly.com/link/174425/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Did You Know Postgres Tables are Limited to 1,600 Columns?

🟢 خلاصه مقاله:
اگر نمی‌دانستید، در Postgres هر جدول حداکثر ۱۶۰۰ ستون می‌تواند داشته باشد. این یک محدودیت سخت در هسته سیستم است و با NULL بودن فیلدها یا TOAST دور زده نمی‌شود. اگر شماره issue 226 در سال 2017 را خوانده باشید، احتمالاً این نکته را به خاطر دارید. این سقف به معنای آن است که طراحی‌هایی با جدول‌های بسیار عریض—مثل هر شاخص یک ستون یا طرح‌های EAV تثبیت‌شده—به‌سرعت به حد می‌خورند. راه‌حل‌های بهتر شامل نرمال‌سازی، تفکیک عمودی، تبدیل ستون‌ها به سطرها برای سنجه‌ها، یا استفاده از JSONB برای ویژگی‌های کم‌استفاده و پراکنده است. جدول‌های خیلی عریض علاوه بر ریسک رسیدن به سقف، هزینه I/O و نگهداری را بالا می‌برند. نتیجه عملی: با در نظر گرفتن حد ۱۶۰۰ ستون، از طرح‌های باریک‌تر و انعطاف‌پذیرتر استفاده کنید و قبل از اعمال مهاجرت‌ها، تعداد ستون‌ها را بررسی کنید.

#Postgres #PostgreSQL #SQL #DatabaseDesign #DataModeling #SchemaDesign #JSONB #SoftwareEngineering

🟣لینک مقاله:
https://postgresweekly.com/link/176989/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy