💭client vs server !

🔥کلاینت کیه ؟ سرور چیه ؟

در شبکه به دریافت کننده اطلاعات client می‌گویند و به ارسال کننده اطلاعات server می‌گویند.

#network

❗️عکسش یه سری چیزاشو نگفتم ولی خوب بود گفتم بزارم (بعدا میگم چی به چیه)

💭ریموت شدن به سرور با ssh

🔥اس اس اچ (ssh) یه پروتکل رمزنگاری شده است که برای ارتباط بین دستگاه ها درون شبکه کاربرد دارد به ویژه برای کنترل و دسترسی به سرورها از راه دور (remote )


برای کانکت شدن به یک سرور باید هویت تایید شود که به دو روش پرتکرار انجام می‌شود :

1️⃣ اولین روش قرار دادن یک username و password برای سرور است .

sudo adduser  <new_username>

بعد از اجرای این command از شما یک پسورد می‌خواهد و تمام.

2️⃣ روش دوم از امنیت بالاتر برخوردار است.
این روش یک جفت کلید که شامل private key و public key هست احراز هویت ی‌شود.

ssh-keygen -t rsa (or dsa , ..)

نکته : در اینجا rsa , dsa , .. روش های رمز نگاری هستند.

بعد از اجرا از شما یک private key و یک public key می‌خواهد.

ssh <username>@<hostname>

حالا وقتی ssh بزنیم به یه server از ما اون public key که انتخاب کردیم رو میخواد!!

حالا هر سروری که بسازید و بخواهید به آن ssh بزنید یک public key می‌خواهد که باید آن را حفظ باشید برای اینکه با یک پسورد به تمام سرورها متصل بشوید می‌توانید از private key استفاده کنید.
با اجرا این command:

ssh-copy-ip <username>@<hostname>

نکته : در اینجا فایل public باید به اسم id_rsa.pub و private
باید به اسم id_rsa باشد در غیر اینصورت باید ssh-copy-ip ، include کرد .

❓️کجا میتونم فایل ها رو ببینم

/home/user/.ssh

❓️از کجا بفهمم private key من در سرور ذخیره شده و دیگه نیازی به public key نیست :

1) ssh <username>@<hostname>
2) cd ~.ssh
3) cat authorized_key

❓️و حالا اینکه از کجا بفهمیم یه سرور هایی رو میتونیم از private key استفاده کنیم
باید بهتون بگم که تویه همون مسیر

home/user/.ssh

یه فایلی هست به اسم known_hosts که توش هر سروری که بشه باهاش private key زد رو نشون میده .

💡 الان دیگه به راحتی میشه به سرور دسترسی پیدا کرد و و حتی data انتقال داد که بعداً روشش رو بهتون میگم.

#network #linux

💭از browser تا web server :

🔥وقتی شما روی URL یا همون لینک کلیک میکنید چه اتفاقی می افته؟

>وب سرور چیکار میکنه❓️
سرو میکنه اطلاعات رو توسط پروتکل Http !

شما برای وارد شدن به یک وب سایت و دسترسی به محتوای آن نیاز به ip اون وب سایت یا سرور دارین .

ولی ما برای هر وب سایت یا سرور فقط دامین اون ها ( مثل google.com) رو بلدیم
خب حالا باید چیکار کرد ❓️

اینجا DNS به کمک ما میاد !

چیکار میکنه ؟
دی ان اس (DNS ) مثل یک دفترچه تلفن تو خودش نگه می‌داره که مثلا ip گوگل ، 216.239.38.120 هس و یا مثلا example.com , آی پیش ۱.۲.۳.۴ هس (مثلا)

>هر سرور یک name server داره که DNS server ها به صورت زنجیره ای وصل هستن به اون ها و ip سرور رو برای ما میگیرن.

گفتیم برای ارتباط بین دو سیستم نیاز به دو ip و دو port داریم ! پس ip DNS و ip name server کجاست ؟
ip DNS :
~. resolve.conf در فایلی به اسم

ip name server:
وقتی که ما دامین میخریم همون جا ست میکنیم که ip name server چی باشه !

خب پس متوجه شدیم میشه ip سرور ها و وب سایت های مختلف رو توسط DNS بررسی کرد .

حالا ip رو گرفتیم بعدش چی میشه ؟

حالا توسط پروتکل ip/tcp/http یک request http به وب سرور میزنیم و یک response http توسط وب سرور دریافت میکنیم !

(نکته : این ip که ما میگیریم ip خود سایت یا وب سرور نیست بلکه ip CDN هست که بعدا میگم راجبش )

طبق این پروتکل(TCP) ، سه مرحله باید طی بشه که browser و web server به هم متصل بشن :

3_way handshake :

مرحله اول : syn هست که browser یک بسته اولیه برای web server می‌فرسته که چک کنه در این بین پروتکل رمزنگاری چک شده یا اینکه بسته به صورت کامل رسیده به مقصد یا نه

مرحله دوم : syn / ack
در این مرحله web server تایید خودش رو برای درست رسیدن بسته انجام میده

مرحله سوم : ack
در این مرحله browser تایید میکنه که تاییدیه web server بدست آورده

خب در response که دریافت میکنیم پکت های html , javascript, css , .. هست که توسط render و javascript interpreter مرورگر تبدیل به data های قابل درک می‌شوند!

#network

طلوع غم انگیز پاییز

گوگل بهتون رایگان یه شل دبیان بیس میده که 5 گیگ هم حافظه داره روش داکر، گیت، پایتون و پی اچ پی و ... هم از قبل نصب کرده


یه ادیتور هم داره

shell.cloud.google.com

💭SSL or TLS

🔥پروتکل SSL (Secure Sockets Layer) یا نسخه جدیدتر آن، TLS (Transport Layer Security)، پروتکلی است که به طور گسترده برای ایجاد ارتباطات امن بین کاربران و سرورها استفاده می‌شود. SSL دو قابلیت مهم را فراهم می‌کند:

1)رمزنگاری دوطرفه : یعنی اطلاعاتی که بین کاربر و سرور رد و بدل می‌شود به‌صورت رمزنگاری‌شده ارسال و دریافت می‌شود. این باعث می‌شود که اگر شخص ثالثی بخواهد در میانه‌ی راه اطلاعات را شنود کند، به‌خاطر رمزنگاری، نتواند محتوای اطلاعات را بخواند یا اگر دسترسی پیدا کرد با یک سری حروف نامعلوم رو به رو شود.

2) حفظ یکپارچگی اطلاعات : این پروتکل همچنین تضمین می‌کند که داده‌هایی که بین کاربر و سرور منتقل می‌شود، در مسیر دستکاری نشده‌اند. اگر در جریان انتقال داده‌ها، تغییرات غیرمجاز انجام شود، SSL این تغییرات را شناسایی می‌کند و به کاربر هشدار می‌دهد.

3) ایجاد نهایی پکت‌ها : بعد از اینکه مرورگر کاربر درخواست را ساخت، بسته‌ی نهایی توسط پروتکل‌های شبکه در سیستم کاربر تولید و سپس به سرور ارسال می‌شود. بسته‌های ارسالی شامل اطلاعات رمزنگاری شده هستند که فقط سرور مقصد می‌تواند آنها را بازگشایی و بررسی کند. این ارتباط به‌صورت مستقیم و امن بین کاربر و سرور انجام می‌شود.


نقش ابزارهایی مثل Burp Suite در حملات MITM:

برپ سوییت یکی از ابزارهای معروف برای انجام حملات "Man in the Middle" (MITM) است. در این حالت، به جای ارتباط مستقیم با سرور، ترافیک از طریق Burp Suite عبور داده می‌شود. Burp به عنوان یک واسطه بین کاربر و سرور عمل می‌کند.

قابلیت ها :

قابلیت Traffic Inspection: برپ می‌تواند ترافیک رمزنگاری‌شده SSL را باز کند و به کاربر اجازه دهد محتوای درخواست‌ها و پاسخ‌ها را مشاهده کند. این کار با استفاده از یک گواهی SSL تقلبی که Burp Suite ایجاد می‌کند، انجام می‌شود. کاربر یا مرورگر باید این گواهی را بپذیرد تا Burp بتواند به ترافیک دسترسی پیدا کند.

قابلیت Traffic Modification: علاوه بر مشاهده ترافیک، Burp این امکان را فراهم می‌کند که کاربر بتواند محتوای بسته‌ها را تغییر دهد. مثلاً می‌توان درخواست‌هایی که به سرور ارسال می‌شود یا پاسخ‌هایی که از سرور دریافت می‌شود را دستکاری کرد.

مراحل دقیق عملیات MITM با Burp:

ابتدا، ارتباط از مرورگر کاربر به Burp Suite برقرار می‌شود، به‌جای اینکه مستقیم به سرور متصل شود.
برپ بسته‌ها را از مرورگر دریافت می‌کند و به‌طور موقت رمزنگاری را باز می‌کند (Decrypt). این کار با استفاده از گواهی جعلی SSL که قبلاً نصب شده است، امکان‌پذیر است. سپس کاربر می‌تواند بسته را مشاهده یا تغییر دهد.
در نهایت، Burp Suite دوباره بسته را رمزنگاری کرده و به سرور اصلی ارسال می‌کند.

》این عملیات به ما امکان بازبینی و دستکاری ترافیک در یک ارتباط امن را می‌دهد، در حالی که برای کاربر یا سرور تفاوتی در ظاهر ارتباط مشاهده نمی‌شود.

💭انواع احراز هویت در web applications :

احراز هویت با نام کاربری و رمز عبور :
این روش رایج‌ترین نوع احراز هویت است که کاربران با وارد کردن نام کاربری و رمز عبور خود به وب اپلیکیشن دسترسی پیدا می‌کنند

احراز هویت دو مرحله‌ای (2FA):
این روش شامل دو مرحله برای تأیید هویت کاربر است. معمولاً پس از وارد کردن نام کاربری و رمز عبور، کاربر باید یک کد تأیید که به تلفن همراه یا ایمیل او ارسال می‌شود را وارد کند.

احراز هویت مبتنی بر توکن : (Token-Based Authentication) یکی از روش‌های محبوب و امن برای تأیید هویت کاربران در وب اپلیکیشن‌ها و APIها است. در این روش، پس از ورود موفق کاربر، یک توکن به او داده می‌شود که می‌تواند برای دسترسی به منابع مختلف استفاده شود

احراز هویت اجتماعی:
این روش به کاربران اجازه می‌دهد تا با استفاده از حساب‌های کاربری خود در شبکه‌های اجتماعی (مانند فیس‌بوک، گوگل و توییتر) وارد وب اپلیکیشن شوند

احراز هویت بیومتریک:
این روش شامل استفاده از ویژگی‌های بیومتریک مانند اثر انگشت، تشخیص چهره یا صدا برای تأیید هویت کاربر است.
>> برای اطلاعات بیشتر :
https://www.baeldung.com/cs/authentication-web-apps


مراحل احراز هویت مبتنی بر توکن (Token-Based Authentication) :

1️⃣ورود کاربر: کاربر با وارد کردن نام کاربری و رمز عبور خود به سرور درخواست می‌فرستد

2️⃣تأیید هویت: سرور اطلاعات کاربر را بررسی می‌کند. اگر اطلاعات صحیح باشد، سرور یک توکن تولید می‌کند

3️⃣ارسال توکن: توکن تولید شده به کاربر ارسال می‌شود. این توکن معمولاً به صورت یک رشته متنی (مانند JWT - JSON Web Token) است.

4️⃣استفاده از توکن: کاربر می‌تواند این توکن را در درخواست‌های بعدی خود به سرور ارسال کند. معمولاً توکن در هدر HTTP (به عنوان مثال، در هدر Authorization) ارسال می‌شود.
>> در مورد هدر های HTTP قبلا توضیح دادم !

5️⃣تأیید توکن: سرور توکن را بررسی می‌کند تا مطمئن شود که معتبر و غیر منقضی است. اگر توکن معتبر باشد، سرور به درخواست کاربر پاسخ می‌دهد

رایج ترین نوع احراز هویت از طریق توکن :

یکی از انها JWT (JSON Web Token):

یکی از رایج‌ترین انواع توکن‌ها است که شامل سه بخش (Header، Payload و Signature) است و می‌تواند اطلاعاتی مانند شناسه کاربر و زمان انقضا را در خود داشته باشد.
>> در مورد Payload و signature بعدا بیشتر توضیح میدم

حالا JWT از الگوریتم های مختلفی استفاده میکنه که پرکاربرد ترین اون ها :

HS256 , RS256

الگوریتم HS256 چیست؟

‏HS256 یک الگوریتم امضای متقارن هست. در رمزنگاری متقارن، هم برای امضا و هم برای تأیید توکن از یک کلید استفاده میشه که بهش private key میگیم ( تعریف الگوریتم متقارن ) .

الگوریتم ‏RS256 چیست؟

‏RS256، یک الگوریتم امضای نامتقارن هست. برخلاف HS256، از یک جفت کلید استفاده میکنه ، یک private key برای امضای توکن و یک public key مربوطه برای تأیید اون( تعریف الگوریتم نامتقارن ) .این امر RS256 را برای سناریوهایی که طرف‌های امضا و تأیید موجودیت‌های متفاوتی هستن، مانند سیستم‌های توزیع‌شده یا زمانی که توکن‌ها در سرویس‌های مختلف به اشتراک گذاشته میشه، ایمن‌تر میکنه.

برای استفاده از private key و public key داریم:

// sign token with private key
jwt.sign(payload, prvkey, {
      expiresIn: exp,
      algorithm: 'RS256',
    });

// verify token with public key
jwt.verify(token, pubkey, { algorithms: ['RS256'] })

#jwt

💭HSTS چیه .

🔥 هدف: HSTS برای محافظت از وب‌سایت‌ها در برابر حملات MITM(man-in-the-middle)
طراحی شده است، مانند حملات کاهش پروتکل و سرقت cookie. با اجباری کردن استفاده از HTTPS، اطمینان حاصل می‌کند که تمام ارتباطات بین browser و server رمزگذاری شده است.( ssl handshake)

زمانی که یک مرورگر هدر HSTS را از یک server دریافت می‌کند، این دستور را برای یک دوره مشخص (که با دستور max-age تعیین می‌شود) به خاطر می‌سپارد. در این مدت، اگر کاربر سعی کند به سایت از طریق HTTP دسترسی پیدا کند، مرورگر به‌طور خودکار درخواست را به HTTPS تبدیل می‌کند.

Strict-Transport-Security: max-age=31536000; includeSubDomains ;preload

- max-age
زمان (به ثانیه) را مشخص
می‌کند که مرورگر باید به یاد داشته باشد که HTTPS را اجباری کند.

- includeSubDomains نشان می‌دهد که HSTS باید به تمام زیر دامنه‌های سایت نیز
اعمال شود.

- preload
میگه که کاربر حتی اگر قبلا هم با HTTPS وارد نشده بود
باید HSTS رخ بده و HTTP رو تبدیل کنه به HTTPS .

برای استفاده از HSTS باید در وب سرور خود ذخیره کنیم :

<VirtualHost *:443>
      ServerName yourdomain.com

      SSLEngine on
      SSLCertificateFile /path/to/yourdomain.crt
      SSLCertificateKeyFile /path/to/yourdomain.key

      Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

</VirtualHost>

خب حالا یه نکته ای که هست باید قبل از استفاده از HSTS گواهی ssl وب سرور امضا شده باشد :

1. انتخاب نوع گواهی SSL

قبل از هر چیز، باید نوع گواهی SSL مورد نیاز خود را انتخاب کنید. انواع رایج گواهی‌ها عبارتند از:

- DV (Domain Validation): تأیید هویت دامنه. سریع‌ترین و ارزان‌ترین نوع گواهی.
- OV (Organization Validation): تأیید هویت سازمان. نیاز به تأیید هویت سازمان دارد.
- EV (Extended Validation): تأیید هویت گسترده. بالاترین سطح تأیید هویت و امنیت.

2. انتخاب یک مرکز صدور گواهی (CA)

مرکز صدور گواهی (CA) را انتخاب کنید. برخی از گزینه‌های رایج شامل:

- Let's Encrypt (رایگان)
- DigiCert
- Comodo
- GlobalSign

3. ایجاد یک درخواست گواهی (CSR)

برای دریافت گواهی SSL، باید یک درخواست گواهی (CSR) ایجاد کنید. این کار معمولاً از طریق وب سرور انجام می‌شود. مراحل ایجاد CSR :

openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key

اطلاعات مورد نیاز را وارد کنید (مانند نام دامنه، نام سازمان و غیره).

4.ارسال CSR به CA

پس از ایجاد CSR، آن را به مرکز صدور گواهی ارسال کنید. این کار معمولاً از طریق وب‌سایت CA انجام می‌شود. شما باید اطلاعات مربوط به دامنه و سازمان خود را نیز ارائه دهید.

5.تأیید هویت

CA هویت شما و دامنه‌تان را تأیید می‌کند. این فرآیند ممکن است شامل ارسال ایمیل به آدرس‌های ثبت شده دامنه یا تأیید اطلاعات سازمان باشد.

6. دریافت گواهی SSL

پس از تأیید هویت، CA گواهی SSL را صادر می‌کند و آن را به شما ارسال می‌کند. این گواهی معمولاً شامل یک فایل با پسوند .crt است.

نصب گواهی :

<VirtualHost *:443>
      ServerName yourdomain.com

      SSLEngine on
      SSLCertificateFile /path/to/yourdomain.crt
      SSLCertificateKeyFile /path/to/yourdomain.key

      
  </VirtualHost>

#HSTS

💭ورژن های HTTP :

🔥پروتکل HTTP یکی از اصلی‌ترین پروتکل‌های وب است که برای انتقال داده‌ها بین مرورگر و سرور استفاده می‌شود.
این پروتکل چندین نسخه دارد که هر یک از آنها با بهبودها و تغییراتی همراه بوده‌اند. تفاوت‌های کلیدی میان این نسخه‌ها را می‌توان در عملکرد، امنیت و کارایی مشاهده کرد. در ادامه، به تفاوت‌ نسخه‌های مختلف آن می‌پردازیم:

ورژن HTTP/0.9
این نسخه ابتدایی پروتکل HTTP است که در سال 1991 توسعه داده شد.
فقط از درخواست‌های GET پشتیبانی می‌کرد.
هدرهای HTTP (مانند نوع محتوا، طول محتوا و ...) را نداشت؛ بنابراین تنها قابلیت ارسال فایل‌های HTML داشت.
پاسخ‌ها فقط شامل بدنه بودند، یعنی هیچ اطلاعات اضافی مانند نوع یا طول محتوا ارسال نمی‌شد.
به دلیل نبود پشتیبانی از هدرها و انواع درخواست‌های دیگر، بسیار محدود بود و کاربری‌های پیچیده‌تر را پشتیبانی نمی‌کرد.

ورژن HTTP/1.0 (سال 1996)
هدرهای HTTP معرفی شد که امکان ارسال اطلاعات بیشتر درباره درخواست‌ها و پاسخ‌ها را فراهم می‌کرد.
از روش‌های متعدد HTTP مانند GET، POST و HEAD پشتیبانی می‌کرد.
قابلیت مشخص کردن نوع و طول محتوا (Content-Type و Content-Length) به پاسخ‌ها افزوده شد.
از اتصال غیرفعال (non-persistent connection) استفاده می‌کرد؛ به این معنا که پس از ارسال هر درخواست و دریافت پاسخ، اتصال بسته می‌شد. این موضوع باعث افزایش زمان تاخیر می‌شد، چون برای هر درخواست یک اتصال جدید ایجاد می‌شد.

ورژنHTTP/1.1 (سال 1997)
ارتباط مداوم (persistent connection) معرفی شد، که اجازه می‌دهد یک اتصال بین کلاینت و سرور برای چندین درخواست باز بماند، و این موضوع به شدت کارایی شبکه را افزایش داد.
پایپ‌لاینینگ (pipelining) معرفی شد، که به مرورگر اجازه می‌دهد چندین درخواست را بدون انتظار برای پاسخ درخواست قبلی ارسال کند.
بهبودهای مربوط به کشینگ (caching) ارائه شد تا کارایی بارگذاری صفحات بیشتر شود.
پشتیبانی از چندین میزبان در یک سرور (از طریق هدر Host)، که برای میزبانی مجازی چندین دامنه روی یک آدرس IP ضروری بود.
پشتیبانی از فشرده‌سازی و رمزگذاری محتوا (مثل Gzip و Chunked Transfer Encoding) برای کاهش حجم انتقال داده‌ها و افزایش سرعت.


ورژن HTTP/2 (سال 2015)
قابلیت چندپخشی (multiplexing): چندین درخواست و پاسخ می‌توانند هم‌زمان از طریق یک اتصال TCP منتقل شوند. این باعث کاهش تاخیر شبکه می‌شود.
استفاده از فریم‌های باینری به جای متن خالص: این تغییر باعث می‌شود داده‌ها سریع‌تر و بهینه‌تر ارسال شوند.
اولویت‌بندی درخواست‌ها: کلاینت‌ها می‌توانند اولویت ارسال درخواست‌ها را تعیین کنند تا منابع مهم‌تر زودتر بارگذاری شوند.
فشرده‌سازی هدرها (HPACK): این قابلیت به منظور کاهش حجم هدرهای HTTP و در نتیجه افزایش کارایی معرفی شد.
بهبود امنیت: HTTP/2 عمدتاً با TLS (نسخه امن پروتکل) استفاده می‌شود، که این باعث افزایش امنیت ارتباطات می‌شود.

ورژن HTTP/3 (نسخه نهایی در سال 2022)
مهم‌ترین تغییر در HTTP/3 استفاده از پروتکل QUIC به جای TCP است. QUIC یک پروتکل لایه انتقال جدید است که با هدف کاهش تاخیر و بهبود کارایی، به‌ویژه در شرایط شبکه‌های ناپایدار (مانند اتصالات موبایل) طراحی شده است.
اتصال سریع‌تر: QUIC از UDP استفاده می‌کند که در مقایسه با TCP نیاز به تایید اتصال اولیه کمتری دارد، بنابراین زمان تاخیر اولیه (RTT) کاهش می‌یابد.
پشتیبانی بهتر از چندپخشی (multiplexing): در HTTP/2 اگر یک بسته گم شود، همه جریان‌ها باید منتظر بازیابی آن بسته بمانند، اما در HTTP/3 هر جریان به صورت مستقل عمل می‌کند.
امنیت پیش‌فرض: QUIC با TLS نسخه 1.3 یکپارچه شده است، بنابراین از ابتدا از رمزنگاری قوی برای ارتباطات استفاده می‌کند.

#HTTP

اگه سایتتون پشت کلادفلر هست الان یه ویژگی جدید به اسم Speed Brain رو داریم، با فعال کردنش میاد با تحلیل رفتار کاربر صفحات احتمالی که کاربر معمولا طی میکنه‌رو prefetch میکنه، مثلا یه محصول خاص رو کاربر میبینه، مرورگر میاد محصولات مشابه که شما پایین این محصول گذاشتید رو قبل از کلیک کاربر دریافت میکنه و به صورت آماده داره، حالا وقتی کاربر روی محصولات مشابه کلیک کنه بدون اینکه لودینگ‌رو ببینه در چند میلی‌ثانیه صفحه براش باز میشه.
کلادفلر برای اینکه به سایت شما فشار نیاد نسخه کش شده خودش‌رو به مرورگر ارسال میکنه، یعنی اگه کش کلادفلر خاموش باشه این ویژگی کار نمیکنه.
فعلا فقط روی مرورگر کروم و کروم‌بیس‌ها از نسخه ۱۲۱ به بعد کار میکنه ولی با توجه به سهم ۷۰ درصدی کروم فعال کردنش کمک زیادی به سرعت بیشتر سایت شما میکنه.

💭SQL injection

🔥نقطه‌ای که یک برنامه وب که از SQL استفاده می‌کند می‌تواند به تزریق SQL تبدیل شود، زمانی است که داده‌های ارائه شده توسط کاربر در پرس و جوی SQL قرار بگیرد می‌شوند.
یعنی در قسمت <Query>? در URL تست نفوذ خودش رو انجام بده .

چه زمانی اتفاق میوفته؟

سناریوی زیر را در نظر بگیرید که با یک وبلاگ آنلاین مواجه شده‌اید و هر ورودی وبلاگ دارای یک شماره شناسایی منحصر به فرد است. ورودی‌های وبلاگ ممکن است به صورت عمومی یا خصوصی تنظیم شوند، بسته به اینکه آیا برای انتشار عمومی آماده هستند یا خیر. URL هر ورودی وبلاگ ممکن است به این شکل باشد:

https://website.thm/blog?id=1

از URL بالا، می‌توانید ببینید که ورودی وبلاگ انتخاب شده از پارامتر id در رشته پرس و جو (Query string) می‌آید. برنامه وب نیاز دارد که مقاله را از SQL بازیابی کند و ممکن است از یک command SQL استفاده کنه :
بیایید فرض کنیم که مقاله با شماره شناسایی 2 هنوز به عنوان خصوصی قفل شده ، بنابراین نمی‌توان آن را در وب‌سایت مشاهده کرد. اکنون می‌توانیم به جای آن URL زیر را فراخوانی کنیم:

https://website.thm/blog?id=2;--

نتیجه Query آن به SQL :

SELECT * from blog where id=2;-- and private=0 LIMIT 1;

نقطه‌ویرگول (;) در URL پایان عبارت SQL را مشخص می‌کند و دو خط تیره (--) باعث می‌شود که همه چیز بعد از آن به عنوان یک نظر (comment) در نظر گرفته شود. با انجام این کار، در واقع شما فقط عبارت زیر را اجرا می‌کنید:

SELECT * from blog where id=2;--

که مقاله‌ای با شماره شناسایی 2 را بازمی‌گرداند، چه به صورت عمومی تنظیم شده باشد و چه نباشد!!

این تنها یک مثال از آسیب‌پذیری تزریق SQL از نوعی به نام تزریق SQL در باند (In-Band SQL Injection) بود؛ در مجموع سه نوع وجود دارد: In-Band ، Blind و Out-of-Band که بعدا بیشتر میگم درموردش.

#SQLI #SQL_Injection

💭خب حالا که یه دیدی از SQL injection پیدا کردیم باید ببینم کجا میشه از این آسیب پذیری نفوذ کرد:

🔥در هر پکت HTTP که ارسال میشه توسط کاربر سایت که حالا میتونه شامل ارسال : username ، password ، email یا اینکه میتونه استخراج دیتا باشه که توسط ادمین سایت صورت میگیره مثل : user Agent یا cookie و ...
در تمام این موارد ممکنه سایت با دیتابیس تعامل داشته باشه که هدف ما هست.
اول با چند تا مفهوم آشنا بشیم:

بریک ( break ) کردن:
برای خارج شدن از یک رشته به کار می‌رود مثلا در این URL :

https://website.thm/blog?id=1 'order by 1

سینگل کوت ( ' ) به معنای خارج شدن از یک رشته است . اگر فرض کنیم دیتابیس به این صورت است موقع گرفتن username و password یک کاربر :

select * from credentials where username = '$username' and '$password'

با وارد کردن URL بالا چنین Query به دیتابیس زده خواهد شد :

select * from credentials where username = 'x '  '  and password = 'y'

در این Query فقط username چک خواهد شد که آیا درست هست یا خیر و اگر درست بود در سایت لاگین میکنه ( فقط با داشتن ! username ).

فیکس ( Fix ) کردن :
به این معنی هست جلو جلوی ارور هایی که قرار هست اتفاق بیافتد را بگیری مثلا در همان مثال بالا :

select * from credentials where username = 'x '  '  and password = 'y'

همانطور که میبینیم یک رشته ناخوانا شامل :' and password = 'y هست که باید از بین برود چطوری ؟

بعد از break کردن باید خطا ها را Fix کنیم ( یعنی عاملی که باعث ایجاد ارور میشه را حذف کنیم )
با ( -- یا # و ...) میشه اون جایی که باعث ارور میشه حذف کرد و کاری کنه database اون ها رو اجرا نکنه مثلا :

select * from credentials where username = 'mamad '#' and password ='mamad'

همانطور که میبینین اروری که میگرفتیم الان کامنت شده و دیگه SQL اون رو تفسیر نمیکنه (:
باعث میشه هر چیزی که بعد از username هست خوانا نباشه و همین موجب به لاگین بدون پسوورد میشود.
در پست های بعد درباره انواع SQL Injection میگم بهتون (:

#SQLI #SQL_Injection

#SQLI #SQL_Injection

کوکی ( cookie ) چیه ؟

یه data هست که به صورت خودکار توسط web server ست میشه رویه browser ما .

حالا به چه کاری میاد ؟
فرض کنین وارد سایت دیجی کالا میشین و ثبت نام میکنین برای اولین بار . حالا بعد که کارتون تموم شد اون دیوایسی که باهاش در دیجی کالا وارد شدید را کنار میزارین و بعد از چند روز دوباره به سایت دیجی کالا می‌روید اما حالا دیگر صفحه ورود برای شما نمی‌آید و مستقیماً به اکانت خود دسترسی دارید اما چطور؟
با بیان ساده بخوام بگم دیجی کالا ما رو یادش می‌مونه و دیگه ازتون ایمیل و پسورد نمی‌خواد.
این قضیه با استفاده از کوکی‌ها قابل انجامه.

کوکی یه رشته است که تا مادامی که روی دیوایس شما باشد به معنای تایید هویت ( Authentication ) و دسترسی شما (privilege ) بدون login در وب سایت است.
یه سری flag داره که مشخص میکنه چطوری کار کنه :
(در آخر سر بهتون syntax استفاده از این flag ها رو میگم)

1- domain

به معنی ست کردن کوکی در domain مشخص شده ای هست.

2-path

به معنی ست کردن کوکی در مسیرهای (route )مشخص در یک web site است.
مثلا فرض کنین یه web site چند تا route داره :

site.com/login
site.com/class

با flag path مبشه مشخص کرد مثلا فقط برای /login کوکی ست بشه !

3- Secure

فقط برای پروتکل HTTPs کوکی ست میشه.

4 - HttpOnly

این فلک فقط برای پروتکل HTTP , HTTPs کوکی ست خواهد کرد و فقط اون‌ها می‌تونن به کوکی‌ها دسترسی داشته باشند.
به عبارت دیگه therd party های مختلف مثل : extension ها یا کد ها Javascript نمیتونن اون ها رو select کنن و از اون‌ها استفاده کنند.

5- samesite


این flag مشخص می‌کنه که فقط برای origin یکسان کوکی انتقال پیدا کنه یا نه.

ببینید بذارید اول توضیح بدم که کوکی از یه سایتی به یه سایت دیگه منتقل بشه چی میشه؟
فرض کنید من یک هکر هستم و یه وب سایتی دارم که شما وارد ن وب سایت می‌شوید در سایت من یک سری کد html هست که باعث میشه ما به سایت‌های مختلف درخواست ارسال کنید ( میتونه با تگ های مختلف مثل : iframe , image , script باشه . در script از ویژگیی به نام xmlHttpRequest استفاده میشه که بعدا بیشتر میگم و یهتون نمونه کد هاش رو میدم) .
حالا یکی از اون وب سایت‌ها فرض کنید یک درگاه بانکیست که من توانستم کوکی‌های شما را از آن استخراج کرده ( چون قبلا در ان لاگین کرده و یک سری cookie به شما داده ) و استفاده کنم که این استفاده باعث تایید هویت من به جای شما است و می‌توانم وارد اکانت شما بشم.

توضیحات بیشتر درمورد فلگ samesite :
میتونه مقدار های مختلفی داشته باشه مثل :

samesite = Strict

این ویژگی نشون میده که فقط آنهایی می‌توانند دسترسی به کوکی داشته باشند که origin های آنها مثل یکدیگر باشد.
مثل دو وب سایت :

x.site.com
Y.site.con:443`

این دو origin های مشابهی دارند.

samesite = none

این قابلیت امکان دسترسی کوکی در هر origin به هر origin دیگر را می‌دهد.

samesite = Lax

این قابلیت هم مثل قابلیت بالایی است ولی یک شرط دارد آن هم اینکه باید ویژگی top level navigator در وب سایت اولیه وجود داشته باشه ( خلاصه بخوام بگم یعنی اینکه در وب سایت اولیه با استفاده از کلیک کردن وارد وب سایت مقصد بشویم . استفاده از تگ a در HTML )

6 - expire

زمان منقضی شدن cookie رو مشخص میکنه .


حالا چطوری cookie ست کنیم برای web site ؟
مثلا در PHP سینتکسش اینه :

setcookie(name, value, expire, path, domain, secure, httponly);

یا در JavaScript به عنوان مثال :

document.cookie = "username=John Doe; expires=Thu, 18 Dec 2013 12:00:00 UTC; path=/";

خیلی طولانی شد 🦦

💭Union based:

🔥ببینید وقتی شما request می‌زنید به یک URL سه تا حالت داره : ( اگر با SQL در تعامل باشه )

1_ اینکه یه جوابی به شما برگردونه
(مثلا در خرید از یه کتاب فروشی ، به شما بگه چند تا از این کتاب موجود هست )

2_اینکه یه نتیجه ای از جواب رو به شما برگردونه

(مثلا در همون مثال بالا به شما به جای اینکه تعداد بگه فقط بگه این کتاب رو موجود داره یا خیر )

3_ اینکه هیج نتیجه ای به شما بر نگردونه.
(مثلا شما یه درخواست GET یا POST ارسال کردین و حالا web site از شما میخواد که اجازه بهش بدین ip , cookie , user Agent, .. ذخیره کنه و در غیر این صورت اجازه کار با سایت رو نخواهید داشت.

چطوری بفهمیم Union داریم ؟
اگه URL این باشه:

https://site.com?news=22

چنین Query میزنه به database :

select * from news where news_id = $newsid ; 

select * from news where news_id = '$newsid' ;

select * from news where news_id =" $newsid " ;

حالا برای تشخیص اینکه آیا Union هست یا نه داریم :

با order by میشه تعداد column های یک database رو استخراج کرد.

Default request:
page/?id=54

Test 1 : 
page/?id=54 order by 1 
page/?id=54' order by 1 #
page/?id=54" order by 1 #

Test 2 : 
page/?id=54 order by 1000
page/?id=54' order by 1000#
page/?id=54" order by 1000#

در بالا اگر :

Default == Test 1

و همچنین
Test 1 != Test 2

شد می‌فهمیم Union داریم (:
حالا چطوری اطلاعات رو استخراج کنیم ؟
گام اول بدست آوردن تعداد column هاست
و می‌توانیم به صورت زیر پیدا کنیم :

page/?id=54 order by 1 # same as default request 

page/?id=54 order by 2 # same as default request

page/?id=54 order by 3 # same as default request

page/?id=54 order by 4 # not same as Default

پس می‌فهمیم 3 تا column داریم
حالا با :

page/?id=54 union select 1,2,3 #

میتونیم اون column که به ما برمیگردونه رو پیدا کرده و توش Payload ها خودمون رو اجرا کنیم برای بدست آوردن data :

مثلا برای بدست آوردن نام database :
(اگر column سوم رو برگردونه )

page/?id=54 union select 1,2,database()#

برای گرفتن table های یک database:

page/?id=54 UNION SELECT table_name FROM information_schema.tables WHERE table_schema = 'your_database_name' --

برای بدست آوردن column های یک database و یک table :

UNION SELECT column_name FROM information_schema.columns WHERE table_name = 'your_table_name' AND table_schema = 'your_database_name' --

و برای بدست آوردن data یک column داریم :

UNION SELECT your_column_name FROM your_table_name LIMIT 1 OFFSET 0 --

#SQLI

هر وقت یه ابزار کاربردی و جالب پیدا می‌کنم، دوست دارم با شما هم به اشتراک بذارم. ولی وقتی این ابزار به حریم شخصی هم اهمیت بده و متن‌باز هم باشه که دیگه عالی میشه!
چند هفته‌ای هست که از نرم‌افزار LocalSend استفاده می‌کنم و واقعا راضیم. این نرم‌افزار به شما اجازه می‌ده که ویدیو، عکس، متن، یادداشت یا فایل‌های دیگه رو بین دستگاه‌هایی که به یک وای‌فای وصلن، رد و بدل کنید. شاید خیلی انقلابی نباشه، اما از چیزی که فکر می‌کنید کاربردی‌تره.
خیلی وقت‌ها ما از چت‌هایی مثل تلگرام برای رد و بدل کردن فایل‌ها و متن‌ها بین دستگاه‌های مختلف (مثلاً فرستادن آدرس بیتکوین از کامپیوتر به گوشی) استفاده می‌کنیم که اصلا خوب نیست چون حریم شخصی‌مون رو به خطر می‌ندازه. LocalSend یه راه راحت و سریع برای حل این مشکل و حفظ حریم شخصیه.
به نظر من، تجربه کاربری این نرم‌افزار خیلی خوبه. همیشه درست کار می‌کنه و هیچ باگی نداره. سرعت انتقال فایل‌هاش هم فوق‌العاده‌ست (چون توی شبکه‌ی محلی هست، می‌تونید فیلم‌های 4K چند گیگابایتی رو خیلی سریع انتقال بدید).

iOS, Android , windows, linux, mac

https://localsend.org/download

#اوپن_سورس