امنیت خود را تامین کنید

با سلام .
چون اغلب در کتاب های آموزشی asp حرفی از امنیت برنامه ها زده نشده بنده قصد دارم اگر شد آموزش هایی درباره امنیت برنامه های تحت وب با asp رو براتون بذارم . مساله ای که باعث میشه خیلی ها گنگ باشن در این زمینه .
اگر مطلب خارجی هم بود میذارم که انشالله یک منبع خوب هم جمع آوری بشه .
اما قبلش مجبورم شما رو کمی راغب کنم به این که این تاپیک رو از یاد نبرید --> پس تحویل بگیرید :
آیا شما هم از هک شدن مداوم سایت خود که بر حسب تصادف با ASP نوشته شده است عصبی شدید ؟
آیا چپ و راست سایت شما مورد هجوم قرار می گیرد ؟
چند بار عبارت کذایی ... Hacked By را در وب سایت خود مشاهده کرده اید ؟
چند بار اقدام به امن کردن برنامه های تحت وب خود که باز هم تصادفا با ASP نوشته شده اند کرده اید ؟

قدم اول :

خودتون رو به جای هکر (!) سایت خودتون بذارید . اولین جایی که چشمک میزنه واسه کرم ریختن کجاست ؟؟؟
خیلی سخت نیست ... صفحه ورود کاربر/مدیر/اعضا
حالا 2 حالت داره . یا اینکه این صفحه عمومیه مثل ورود اعضا یا اینکه اختصاصیه مثلا فقط ورود مدیر. دقت کنید که صفحه ورود مدیر رو نباید همه بدونن . اگر شما صفحه ورود رو علنی کردید پس کار رو برای هکر ها راحت تر کردید . حداقل بذارید چند دقیقه یا چند ساعتی وقت و اینترنت هکر در پیدا کردن صفحه ورود مدیر تلف بشه . این کار از لحاظ روحی و روانی تاثیر صد در صد روی هکر میذاره . شاید اگه هکر کم حوصله باشه جا بزنه و دیگه کاری به سایت شما نداشته باشه . گاهی اوقات وقتی صفحه ورود مدیر رو همه بدونن و عین باقلوا بذارین کنار سایتتون یه جوری شاید این برداشت بشه که هکرها رو به مبارزه دعوت کردید . البته این جور شوخی ها با افرادی که شوخی سرشون نمیشه اصلا کار منطقی نیست . نکن دوست من ... نکن .

خلاصه : حتی المکان صفحه ورود مدیر عمومی نباشه . دایرکتوری(پوشه اش) معلوم نباشه . یه خورده هم دور از ذهن باشه . البته همه این ها از محکم کاریه . اما اگه خیلی به صفحه ورودتون مطمئن هستید میتونید اون رو به صورت عمومی در وب سایتتون قرار بدید و کمی با هکر شوخی کنید .

تا اینجا ربطی به asp نداشت . داشت ؟؟؟ فکر کنم امشب 2 تا قدم دیگه هم بگم . بعدش هر وقت شد بقیه اش . سعی هم میکنم محاوره ای بنویسم و از اصطلاحات دوری کنم که هم دنبال کردنش راحت تر باشه هم قابل فهم تر باشه .

قدم دوم :

در ادامه مطلب قبلی باید این نکته رو بگم که حالا وقت این رسیده یک صفحه ورود خوب و امن داشته باشین . اصولا قاعده ای که در اکثر سیستم های ورود رعایت میشه اینه که یوزرنیم + پسورد از مراجعه کننده خواسته میشه . بعد میره توی دیتابیس و صحت پسورد تایید میشه . session تشکیل میشه . به صفحه اصلی مدیریت ارجاع داده میشه .
حالا ممکنه یوزرنیم و پسورد همیشه با یک عبارت ثابت سنجیده بشه . یعنی کار به دیتابیس کشیده نشه .
if request("username") = "admin" and request("password")="myadmin" then
session("admin")=true
response.redirect "admin.asp"
else
session("admin")=false
response.redirect "login.asp?msg=error"
end if
اما قضیه بغرنج قضیه همون وارد شدن ورودی کاربر به دیتابیس بدون هیچ گونه عملی رو داده هست . که اگه این قسمت رو رعایت کنید تا حد زیادی امنیت برنامه تون رو تامین کردید .
اینجا درباره تاریخچه و اصول sql injection یا همون تزریق اطلاعات نمی خوام وارد بشم . مقالات بسیار زیاد و توضیحات فراوانی در این زمینه هست . ما فقط میخوام راه مقابله باهاش رو یاد بدیم دیگه بقیه توضیحات "در این مقال نمی گنجد" . اما از اونجایی که ندانسته کار کردن خطاست چندتا منبع میذارم که مطالعه کنید .
http://kapda.ir/pedia/SQL_Injection
http://en.wikipedia.org/wiki/Sql_injection

خب برگردیم به کار خودمون . تامین امنیت برنامه های وب که با asp نوشته شدن .
اما اگه قرار هست که یوزرنیم و پسوردی که وارد می کنیم همین طوری یه دفعه بره تو دیتابیس و جواب بیرون بیاد در یک کلام میشه گفت یک حرکت "هکر شاد کن" .
مهم نیست که دستورات sql ما چطور کار می کنند و به چه روشی به تعیین هویت می پردازن مهم اینه که در همه اونها هر عبارتی که داخل query قرار میگیره یه فیلترینگ کوچیکی بشه .
حداقل برای دوستانی که با access کار می کنن بگم که فیلتر کردن کوتیشن تکی لازم هست .
برای کسانی هم که با sql کار میکنن -- و ; و " لازم هست . البته کاراکترهای دیگه هم هستن مثل تمامی اون چیزهایی که روی دکمه های اعداد درج شدن . مثل !@#$%^&*)(=
پس یک نمونه ضعیف از Query

"SELECT * FROM users WHERE name = '" & userName & "'" & " and pass = '" & password & "'"

و نمونه قابل قبول برای اکسس :

"SELECT * FROM users WHERE name = '" & replace(userName,"'","''") & "'" & " and pass = '" & replace(password,"'","''") & "'"

توضیح : replace برای امن کردن و تبدیل تک کوتیشن به دو کوتیشن به کار رفت .

اما این نکته رو هم یادتون نره که در این الگوریتم session فراموش نشه . چون فرض کنید بدون session بخواین صفحه رو منتقل کنید به admin.asp . خب حالا فرض کنید هکر شانسی مستقیم url رو http://site.com/admin/admin.asp زد . بعد هم میره صفحه ادمین . فردا میاین میبینین سایتتون توسط یه گروه هک شده . پس این وسط نقش login.asp چیه ؟ بعد از صحت رمز ورودی ایجاد یک session که در بقیه صفحات مثل admin.asp بدین ترتیب استفاده بشه :

if session("admin") <> true then

response.redirect "login.asp?msg=sorry you must login"

response.end

end if

خلاصه : یک صفحه ورود نسبتا خوب که معمولا الگوریتم مشخصی هم داره اینه که -->
1)گرفتن یوزرنیم و پسورد از بازدید کننده و فیلتر کردن ' و ; و " و -- و دیگر کاراکترها به وسیله تابع replace
2)تعیین اینکه آیا یوزر نیم و پسورد گرفته شده از بازدید کننده (که صد البته منظورم یوزرنیم و پسورد بعد از اجرای فیلتر و محدود کردن اون) صحیح هست یا نه به وسیله sql و asp .
3)اگه صحیح بود تشکیل session و ارجاع به صفحه اصلی مدیریت و چک شدن session در اون صفحه اصلی و سایر صفحات مدیر برای اینکه یه موقع خدای نکرده هکر مستقیم url رو وارد نکرده باشه .

به امید خدا خوب داره پیش میره و مطالب کپی / پیست شده و ... نیست . فکر کنم سبک مقالات جدی بعضی جاها واسه کلاس بخشیدن به کار خوبه ولی بعضی وقتها برای درک بهتر مطلب این طور نوشتن بهتره .

قدم سوم :

حالا وقت اون رسیده که شما یه خورده با هکر شوخی کنید . حالش رو بگیرید . وقتش رو تلف کنید . خسته اش کنید .
مثلا کافیه برای اینکه با دوست هکرمون یه خورده بازی در بیاریم از این کد استفاده کنیم .

if instr(request("username"),"'") <> 0 and instr(request("password"),"'") <> 0 then

response.write "Thank You admin . Your Username And Password were true"

response.end

end if

خب این کد تعیین میکنه که در username و password آیا کوتیشن به کار رفته یا نه ؟ خب اگه خدای نکرده به کار رفته باشه به هکر پیغام میده که ممنون . شما وارد شدید . رمزتون درست بود . هکر کلی ذوق زده . ولی میبینه هیچ اتفاقی نیفتاد . ولی خوشحاله که سیستم شما رو bypass کرده . خلاصه چند دقیقه کلنجار میره به خیال اینکه کار تمومه ولی دستش به هیچ جا بند نیست . فکر می کنه شاید کوکی درست رو کامپیوترش سیو نشده یا دنبال صفحه اصلی مدیریت میگرده . نه خیر ... شما حسابی اعصاب اون رو بهم ریختید .

خلاصه : از کدها و الگوریتم های تکرار یا منطقی برای خسته کردن و فریب دادن هکر استفاده کنید .

قدم چهارم :

اگه گفتید دومین جایی که برای یک هکر چشمک میزنه در asp چی هست ؟ عوض کردن مقدار url ها چون خیلی تو چشم میزنه . حتی گاهی از دانلود کردن mdb هم بیشتر .

بنابراین هر چی تو url استفاده می کنید که مستقیم میره تو دیتابیس بهتر هست همون روش فیلترینگ که توضیح دادم رو به کار ببرین . البته اینجا یه نکته بسیار بسیار بسیار مهم میمونه و اون هم نوع داده است . چیزی که خیلی از برنامه نویس ها بهش توجه نمی کنن .

این url رو در نظر بگیرید .
http://site.com/news.asp?id=10
خب در نگاه اول اگه هکر خوش شانس باشه id به راحتی میره در یک Query بدون هیچ محدودیتی و باز هکر خوش شانس تر اونیه که دیتابیس mssql باشه . دیگه لازم هم نیست روش های کسل کننده access رو اجرا کنه . در mssql دستش باز هست . حالا ایناش مهم نیست . برنامه امن باشه حالا mssql یا access بر میگرده به قابلیت ، سرعت ، سلیقه و ...
کدی که اون پشت اجرا میشه میتونه یه همچین چیزی باشه :

" select * from news where id = " & request("id")

اما این ضعیف ترین نوع کار هست . همون طور که گفتم منجر به sql injection یا تزریق اطلاعات میشه .
دوستانی که خیلی حواسشون به صفحات ورود هست معمولا این قسمت رو یادشون میره . اگر هم یادشون باشه به فرم صفحه ورود عمل می کنن . به خیال خودشون که دیگه امنیت news.asp در حد اعلای خودش هست . مثلا نمونه کد این دوستان این هست :

" select * from news where id = " & replace(request("id"),"'","''")

اما بهتره عرض کنیم این Query فقط کار هکر رو سخت تر می کنه و محدودیت براش به وجود میاره اما اصلا میتونه هیچ کاری هم با این نداشته باشه . چطوری ؟؟؟!؟!؟!
اینطوریه که اصلا کدی که میخواد وارد کنه توش ' نداشته باشه . یعنی کدهای خودش رو در ادامه id وارد کنه بدون ' . فاجــــــــــــــــــعه ...
http://site.com/news.asp?id=10 or 1=1
اینجا قصد ندارم طریقه extract کردن دیتا از دیتابیس رو بگم . ولی دیدید که حتی بدون کوتیشن کارها پیش میره . پس چاره اینه که چک کنید ببینید آیا این داده ورودی عدد هست یا نه . اما یه راه راحت تر . استفاده از cint . روشی که اتوماتیک وار جلوی ورود کوتیشن رو هم میگیره.

" select * from news where id = " & cint(request("id"))

که میدونید اگه id چیزی غیر از یه مقدار عددی باشه error میده که نمی تونه id رو به int که جز صحیح عدد هست تبدیل کنه .
در این موارد یادتون باشه که سیستمتون رو متکی نکنید به اینکه کلمات رو فیلتر کنه . منظورم اینه که فقط مثلا کلمه union رو فیلتر کنه . اگر میخواین عبارت خاصی رو فیلتر کنید یادتون نره که هکر ممکنه از کدهای معادل یا جایگزین استفاده کنه مثل کدهای هگز و ...
اما اگر درست از این قسمت محافظت کنید هکر کار خاصی نمی تونه بکنه .

خلاصه : در url و جایی که مقدار متغیر ورودی به Query قرار است عدد باشد از cint یا isnumeric استفاده کنید .

قدم پنجم ؟؟؟ شما بگید چی باشه ؟!
اگه همراهی کنید منم خوشحال میشم . مشکل امنیتی بود که در حد سواد من بود در همین تاپیک مطرح کنید .
امشب یه خورده خسته شدم . انشالله بقیه اش رو در روزهای آتی ادامه بدم . در مورد نوع کار هم نظر دارید بگید . همین طوری خوبه یا اینطوری ؟
شخص نفوذگر در این Query می تواند کدهای دلخواه خود را بدون اجازه شما وارد کند و موجبات ایجاد حملات تزریق اطلاعات را به وجود آورد که این کار امنیت برنامه های شما را به مخاطره می اندازد .

قدم پنجم :

با xss آشنایی دارید ؟ همون css یا cross_site_scripting . همش یکیه . کدهای مخربی که سمت کاربر(نه سرور) اجرا میشه . اگه با حفره یه مرورگر تلفیق بشه میتونه کاری کنه کل کاربرهای یک سایت رو سیستمشون تروجان نصب بشه ، کوکی بدزده و کارهایی از این قبیل . اول یه سری بزنید :
http://www.kapda.ir/pedia/XSS
در کل چند نوع xss داریم که درجات مختلفی دارن . منظورم از لحاظ درجه خطر بود . اونایی که خیلی متداول هستن نوع 1 و 2 هستن .
دیگه ما اینجا به انواعش کار نداریم . فقط اصطلاحاتش رو بگم که گوشتون آشنا باشه بهشون .
1) نوع اول که معمولا xss یا css میگن .
2) نوع دوم که باعث میشه کدهای html ، javascript و ... در جایی ذخیره بشن و بعد از هربار لود شدن صفحه اجرا بشن . xss میگن بهشون . سایت معروف securityfocus اسمش رو HTML_Injection گذاشته و باقی سایتها Script_Insertion میگن . همشون یکیه .
حالا بریم به سراغ مباحث امنیتیش تو asp .
این آسیب پذیری وقتی به وجود میاد که ما محتوای یه متغیر رو یه دفعه رو صفحه نمایش بیاریم و دست بر قضا این متغیر از کاربر هم گرفته شده باشه . حالا میتونه این متغیر یک متغیر از طریق POST باشه یا GET .
میتونم بگم راحت ترین مثال و متداول ترین حالت صفحه های کامنت هست . دیگه از این راحت تر . این میشه نوع دوم چون فرض کنید شما به جای اینکه اسم خودتون رو وارد کنید میزنید <noscript> . بعد هم کلا اون صفحه کامنت تا پایین از کار میفته . یا مثلا guestbook یا همون دفترچه مهمان . از نوع اول هم مثال بزنم اینطوری :
login.asp?error_msg=please login
بعد هم اگه برنامه آسیب پذیر باشه error_msg رو یکی توش کد html یا javascript میذاره ولی این حالت درجه خطرش خیلی کمتره چون فقط با لینک دادن میشه از این باگ استفاده کرد .
راه حال مناسب در asp
برای کامنت و صفحاتی از این قبیل :

"Select * from comments where id = 'id'"

rs.addnew

rs("name") = request("name")

rs("comment") = request("comment")

rs.update

یا کد مشابه یک خطیش که از insert into table استفاده میشه باید به این حالت تغییر پیدا کنه :

"Select * from comments where id = 'id'"

rs.addnew

rs("name") = server.htmlencode(request("name"))

rs("comment") = server.htmlencode(request("comment"))

rs.update

توضیح : server.htmlencode کدهای <>& رو تبدیل به حالت نمایش میکنه یعنی دیگه کدهای html ، javascript و ... هکر در صفحه نمایش رندر نخواهند شد .

برای نوع اول هم میتونید از این روش استفاده کنید . فرقی نداره .

response.write request("msg")

که کد مناسبش میشه این :

response.write server.htmlencode(request("msg"))

خلاصه : XSS یا CSS به حملاتی گفته می شود که مهاجم با وارد کردن کدهای html و Javascript و ... باعث اجرا شدن آن کدها در صفحه اجرایی خواهند شد و حتی با این روش می توان مستقیم یک سایت را هک کرد یا کوکی مدیر آن سایت را دزدید . بهتر است بعد از اینکه متغیری که از کاربران گرفته شد و قرار است محتوای آن متغیر نمایش داده شود از تابع Server.Htmlencode استفاده کنید .

قدم ششم :

داشتم با یه نفر از طرفداران open source/php یه خورده اختلاط میکردم میگفتم چه خوب شد asp این باگهای php رو نداره . اگه داشت که مصیبت . register_global که پدر همه رو در اورده (میدونم register global باگ نیستاااا) . بعد file inclusion ، command execution . میدونستید با sql injection یا تزریق اطلاعات میشه در php یک فایل کامند شل درست کرد . بعد اون یارو میگفت اینا همش برتری php نسبت به asp هست که این توابع رو داره . گفتم فعلا که این برتری نصف بیشتر نویسنده های برنامه php رو داغون کرده . بعد همه درجه خطرشون بالا . اگر php این magic_gps رو نداشت الان باید تخته میکرد می رفت .

همه این ها رو گفتم که اگر با این باگها آشنایی دارین و یا فقط اسمشون رو شنیدید خودتون رو درگیر نکنید که فعلا asp از این باگها نداره . البته مثلا xp_cmdshell که با باگ sql injection در mssql اجرا میشه گفت خطرناک ولی این تیپی کسی کد مخرب ننوشته واسه برنامه های asp .
خلاصه اینکه اگه توی asp چند مورد که شاید به 20 تا هم نرسه رعایت کنید و اصول امنیتی کلی که ربطی به asp یا php نداره اون ها رو هم رعایت دیگه میتونید مطمئن به کار خودتون ادامه بدید .
این قسمت ادامه کار sql injection . ببخشید ضد sql injection (لول lol) .
همون طور که در پست های بالاتر اشاره شد برای متغیرهای عددی بی دردسرترین کار همون استفاده از تابع cint هست .
برای ما بقی متغیرها اگه علاوه بر ' جلوی سایر متغیر ها گرفته بشه ضرر نداره . ولی تا اونجایی که میدونم برای بانک اطلاعاتی access همین کافیه . برای ms-sql باید بیشتر احتیاط کنید .

name = replace(request.form("name") , "'","''")

name = replace(request.form("name") , "--","")

name = replace(request.form("name") , ";","")

select * from members where name = 'name'

و همچنین !@#$%^&*)(
اگر همین طور فیلتر کنیم سایر کاراکترهای !@#$%^&*)( بیایم پایین باز یه مشکلی داره کد بالا . البته خطری کسی رو تهدید نمیکنه ولی این نکته رو میگم که موقع کار با replace این موارد از دستتون در نره .
فرض کنید یکی name رو اینطوری مقدار دهی کرد .

member.asp?name= -;-

کد replace میاد ; رو بر میداره بعد هم چون -- ندیده دیگه این تکی ها رو فیلتر نمی کنه بعد name شما به این شکل در میاد :

name = --

توضیح : -- در mssql باعث می شود ما بقی عبارت SQL به اجرا در نیاید . کد مشابه آن در MySQL به این حالت است : */

گفتم زیاد فاجعه نیست ولی خیلی حملات از همین نکات جزیی است .

خلاصه : برای متغیرهای غیر عددی از تابع replace استفاده کنید و کاراکترهای ' و " و ; و -- و () و ... را فیلتر کنید .

دوستان انواع اشتباهات از قبیل فنی ، لغوی ، دیکته و ... بنده رو ببخشید . البته اشتباهات فنی / امنیتی رو نبخشید و مشکلی داره حتما بفرمایید که درست کنم . این که میبینید اکثر کدها به حالت شبه کده چون نمیخوام آموزش asp بدم به این حالت گذاشتم . جایی سوال بود مطرح کنید تا اونجا که بلد باشم جواب میدم .

من Function برای تست کردن UserName به حالت زیر نوشتم که شکا هر کاراکتری را دوست دارین می تونین تویه Array اضافه کنید از نظر سرعت هم که خوب بود

 private Function Check_Spel(Str_word)

    

        Dim IntLen,Char_Not,Ch_Sel,Word

        Dim i,j

        Word = Str_Word

        Char_Not = Array("","@","#","$","'","&","%","-")    

        IntLen = len(Word)

        For i=1 to IntLen

            Ch_Sel = Mid(Word,i,1)

            For j=1 to UBound(Char_Not) 

                if Ch_Sel = Char_not(j) then

                    Check_Spel = ""

                    Exit Function    

                end if

            next

        next

    Check_Spel = Word

    End Function

be_kh کد شما هم میاد کاراکتر به کاراکتر بررسی میکنه درسته ؟!
فکر کنم روی username جواب بده ...

در مورد مطالب فوق اگه سایت برنامه نویس دست آدم رو نمی بست می شد مطالب رو بازتر کرد. یعنی مثال هم زد چون اگه کسی SQL_Injection رو بخواد جلوش رو بگیره اول خودش باید قشنگ بدونه چیه و بدونه که میتونه خیلی خطرناک باشه و خودش تست کنه ولی هزار بار هم من بگم خطرناکه فایده نداره. مطالب میتونه خیلی کاملتر از این هم باشه اما با رعایت این اصول من قول شرف که نه ولی قول معمولی میدم (:لبخند:) که تا 90% سایتش محفوظ خواهد موند :چشمک:

توی فرم هایی که اطلاعاتی رو قراره از سمت کاربر توی دیتا بیس ذخیره کنه علامت بزرگتر و کوچکتر رو هم واسه فیلتر کردن یادتون نره

سلام مطالب مفیدی رو گوش زد می کنید
اگه اطلاعاتی در باره مخفی کردن مسیر های واقعی (urlrewriting) دارین بفرمایید
در این تاپیک در موردش توضویح دادن اما من هنوز با اون مشکل دارم یه مثال اگه دارین بزنید
https://barnamenevis.org/showth...+insert&page=2

سوال من این است که
sessionها امنیت شون در asp3 چگونه است.

اینجور که در مقاله های .net که دوستان نوشتند
session ها هم قابل رد یابی هستند و میشه اونها را اسکن کرد.

اگر امکان داشته باشه کمی در باره امنیت و امن کردن session ها بگویید



با تشکر

توی این مقاله از سایت مایکروسافت در مورد مشخصات یک session در زمان ایجاد و نابودی چیزای جالبی گفته. متن کوتاهه و انگلیسی.
http://www.microsoft.com/technet/pro....mspx?mfr=true

در کل session ها طبق نظر این مقاله قابل ردگیری به آسانی Cookie ها نیستند و اگر برنامه نویس در پایان کار خود آنها را صریحا از بین ببرد، دیگر بسادگی راحی برای دسترسی به مقدار آن نخواهد بود.

quote]

نقل قول:

---

در کل session ها طبق نظر این مقاله قابل ردگیری به آسانی Cookie ها نیستند و اگر برنامه نویس در پایان کار خود آنها را صریحا از بین ببرد، دیگر بسادگی راحی برای دسترسی به مقدار آن نخواهد بود.[/

---

در پایان چی آنها را از بین ببرم هر آن ممکن است که یک clinte ( کاربر) تصمیم بگیره که صفحه اش را ببنده.

خوب البته من می توانم sing out یا log out بنویسم ولی غیر از این روش تشخیص پایان راه دیگه خیلی آسان نیست.

شاید جدید ترین عملیات آماری و روانشناسی در سایتهای مهم این باشه که بتونند مسیر مخاطب خود را حدس بزنند ولی باز تشخیص آخرین صفحه و بعد پاکردن seesion ها خیلی کار آسانی نیست.

در این سایت برنامه نویس دو تا تاپیک جوندار خواندم در باره امنیت .
یکی مربوط به asp3 که در همیجا است و دیگری مربوط به امنیت asp.net است که در بخش توسه ASP.NET نوشته شده است.
در اونجا گفته که Sessins ها بصورت یک coocki در کامپیوتر client توسط asp.net ذخیره می شود و همین مساله باعث می شود که آن کوکی را دیگری هک کند و به این ترتیب session ها لو برود.

آیا در asp3 نیز این مشکل وجود دارد؟

وقتی گفته میشه session ها مانند انبار های موقتی هستند برای ذخیره سازی دادهها هنگامی که یک کاربر به سایت وارد می شود و در هنگامی که بلااستفاده می ماند (کاربر سایت را ترک می کند) باید از بین برود چون در غیر اینصورت باعث افزایش بار بر روی سرور می شود، به طور حتم پس چیزی در کلاینت ذخیره نخواهد شد که قابل ردگیری باشد. بنابراین نظریه ی ذخیره مقادیر Session در کلاینت در یک Cookie به نظر صحیح نمی آید و این Session ها از منابع سرور استفاده می کنند.
دوست عزیزی عنوان کردند نمی توان دقیق تشخیص داد کجا باید مقدار یک Session کاربر را پاک کرد؟! در صورتیکه ما زمانی از Session ها استفاده می کنیم که نیاز به ذخیره سازی داده هایی وجود دارد و مطمئنا این انباره های موقت در برنامه های با سیر حرکتی مشخص استفاده می شوند (سیستم ها خرید و فروش، ثبت نام و ...) یعنی در یک مرحله مشخص مقادیری را ذخیره می کنند و هنگام رسیدن به آخر مسیر هم پاک می شوند. مگر اینکه طراح سیستم جهت موارد عمومی (مثل خوش آمد گویی به کاربر) از این انباره ها استفاده کند که در این حالت هم با تنظیم دقیق میزان عمر Session که بنابه توصیه در این مواقع حداکثر 10 دقیقه خواهد بود، می توان مدیریت خوبی رو ی آنها داشت.

thank you so much

ممنون از مطالب بسیار جالب و کاربردی .
این session و گرفتن username و pass برای صفحه اول درسته! حالا اگه من بخوام user وقتی وارد صفحه خودش و اونجا روی یک لینک دیگه رفت که باز باید امنیت بذاریم که اگه همین کاربر هست بره و اگه کسی بخواد از ادرس مستقیم به اونجا بره نشه! چه جوری این username و password رو با خودش به بقیه لینکهاش هم ببره و چک کنه! ممنون .
بهتر نیس تو یه فایل جداگانه مثلاًcheck.asp بذارین و اول همه صفحه ها اول چک کنه! اگه بله کدهاش رو می شه بگین.ممنون

نقل قول:

---

نوشته شده توسط Parisatt

حالا اگه من بخوام user وقتی وارد صفحه خودش و اونجا روی یک لینک دیگه رفت که باز باید امنیت بذاریم که اگه همین کاربر هست بره و اگه کسی بخواد از ادرس مستقیم به اونجا بره نشه! چه جوری این username و password رو با خودش به بقیه لینکهاش هم ببره و چک کنه

---

دوست عزیز دقت داشته باشید که متغیرهای از نوع Session همانطور که گفته شد تا زمانیکه کاربر در سایت ما در حال گشت و گذار!! هست همچنان پایدار هستند...
بنابراین وقتی مثلا کسی در صفحه 1 نام کاربری و رمز عبور خود را وارد کرد و ما پس از چک کردن مطمئن شدیم اطلاعات درست است و در نهایت یک متغیر از نوع Session به نام Login را اینگونه مقدار دهی کردیم :

Session("Login") = True

در صفحات بعدی مثلا صفحه 2 تنها کافی است که در ابتدای صفحه این تکه کد نمونه را بنویسیم :

IF NOT Session("Login") = True THEN

          Response.Redirect "ErrorPage.asp"

End If

در این تکه کد چک می شود که آیا متغیری با نام Login مقدار True دارد یا خیر؟ بدیهی است چنانچه کاربری بخواهد مستقیماً به این صفحه 2 ما دسترسی داشته باشد، چون اصلا متغیری با نام login قبلا برای وی وجود ندارد ، سیستم باز متوجه شده و شرط کد بالا اجرا و وی به صفحه نمایش خطا هدایت خواهد شد... موفق باشی

IF NOT Session("Login") = True THEN

          Response.Redirect "ErrorPage.asp"

End If

در این تکه کد چک می شود که آیا متغیری با نام Login مقدار True دارد یا خیر؟ بدیهی است چنانچه کاربری بخواهد مستقیماً به این صفحه 2 ما دسترسی داشته باشد، چون اصلا متغیری با نام login قبلا برای وی وجود ندارد ، سیستم باز متوجه شده و شرط کد بالا اجرا و وی به صفحه نمایش خطا هدایت خواهد شد... موفق باشی[/QUOTE]

ممنون از راهنمایی. مشکل من اینه وقتی از iis این صفحات رو چک میکنم کار نمیکنه!
کلاً اگه بخواهم فایلهای asp رو اجرا کنم. باید از iis استفاده کنم؟
مثلاً دو سایت مختلف طراحی کردم .باید تمام فایلهای .asp رو تو root بریزم.راه دیگه ای هست که جدا جدا باشن؟

نقل قول:

---

) نوع دوم که باعث میشه کدهای html ، javascript و ... در جایی ذخیره بشن و بعد از هربار لود شدن صفحه اجرا بشن . xss میگن بهشون . سایت معروف securityfocus اسمش رو HTML_Injection گذاشته و باقی سایتها Script_Insertion میگن . همشون یکیه .

---

آیا می شه بوسیله تابع replace علامتهایی مثل > را تغییر داد و فیلتر کرد؟
اینجور دستورات html بی ارزش خواهند شد.

توضیح : این روش یک جیزی شبیه روش مقابله با injet sql است.

آیا این روش درست است برای مقابله حمله سمت client و حمله html ی ؟

تشکر

نقل قول:

---

نوشته شده توسط khadem1386

آیا می شه بوسیله تابع replace علامتهایی مثل > را تغییر داد و فیلتر کرد؟
اینجور دستورات html بی ارزش خواهند شد.

توضیح : این روش یک جیزی شبیه روش مقابله با injet sql است.

آیا این روش درست است برای مقابله حمله سمت client و حمله html ی ؟

تشکر

---

دوست عزیز در فرم هایی که کاربر داده هایی را وارد می کند و به صفحه پردازش اطلاعات می فرستد باید حتما چک شود که او کاراکترهای غیر مجاز را (< > [ ] ' " \ / و ...) وارد نکرده باشد.حال اینکه به ازای وجود هر کدام از این کاراکترها چه عملی اتفاق بیفتد (تغییر کاراکتر یا نمایش خطا) به طراح سیستم بستگی دارد... موفق باشی

نقل قول:

---

دوست عزیز در فرم هایی که کاربر داده هایی را وارد می کند و به صفحه پردازش اطلاعات می فرستد باید حتما چک شود که او کاراکترهای غیر مجاز را (< > [ ] ' " \ / و ...) وارد نکرده باشد.حال اینکه به ازای وجود هر کدام از این کاراکترها چه عملی اتفاق بیفتد (تغییر کاراکتر یا نمایش خطا) به طراح سیستم بستگی دارد... موفق باشی

---

من منظورم اینکه اگر علامت > را از اطلاعات ورودی کاربران حذف کنیم ( با replace)
دیکه لزومی نداره از چیزی مثلxss یا حمله از نوع java و یا کدهای هک داخل html بترسیم
(رجوع شود به شماره 6 همین تاپیک)

آیا نظر من درست هست یا شماره 6 را دست متوجه نشدم.

من می گم اگر نگذاریم که کاربر علامت > را به هر طریقی داخل DB ما ذخیره کنه دیگه حمله هایی از نوع java کنسل می شه. آیا این حرف درسته؟

مرسی از وقتت.

دوست عزیز من با مطلب شماره 6 که گفتین برخورد نکرده بودم... حق با شماست... قاعدتا با جلوگیری از ذخیره سازی کاراکترهای نامعتبر یا بهتره بگیم نامطمئن! تا حد زیادی پیشگیری از حملات صورت می پذیرد... موفق باشی

پس اگر حق با من است چرا آقای 3nitro آمده اند و از دستور server.htmlencode استفاده کردند؟ و این همه سختش کردن.

خیلی راحت می توان کاراکتر > را بوسیله Replace حذف کرد و دیگر نگران این بخش از حملات که در قسمت تاپیک 6 توضیح دادند نبود.

یعنی اگر این کارکتر > را حذف کنی دیگر یک کد java یی اعتبار نداره.

شاید هم من دارم اشتباه می کنم.

اگر اشتباه می کنم بگید.


تشکر از وقتت

دوست عزیز دلیل این گفته دوستمون (3nitro) رو نمی دونم اما به هر حال این هم یک روش است که بنده به شخصه آنرا نمی پذیرم ...
همان تابع Replace بهتر است...
موفق باشی

ممكنه در مورد نحوه صحيح و امن استفاده از كانكشن استرينگ توضيح بدين؟

من كانكشن استزينگ رو توي فايل webconfig قرار دادم اين كار درسته آيا امكان داره اونو كد كرد كه امنيتش بالاتر بره؟

دوست عزیز چنانچه روش کدگذاری شما قابل اطمینان باشد می توانید به امنیت بالاتری دست پیدا کنید... اما ذر کل اطلاعات حساس را در هنگام ذخیره سازی کدگذاری می کنند نه ارتباط با آنها را... موفق باشی

نقل قول:

---

نوشته شده توسط kashaneh

دوست عزیز چنانچه روش کدگذاری شما قابل اطمینان باشد می توانید به امنیت بالاتری دست پیدا کنید...

---

لطفاً براي روش كدگذاري كانكشن استرينگ راهنمائي بفرمائيد.

نقل قول:

---

اطلاعات حساس را در هنگام ذخیره سازی کدگذاری می کنند نه ارتباط با آنها را

---

دوست عزیز دقت بفرمائید که گفتم اطلاعات هنگام ذخیره سازی کدگذاری شوند نه اینکه فایل ارتباطی کد گذاری شود... فایل ارتباطی در صورت کد شدن باید مکانیزمی جهت دیکد شدن داشته باشد که بنده اطلاعی از آن ندارم... اما در مورد کد کردن اطلاعات در بانک اطلاعاتی تاپیک های مختلفی در این تالار موجود است که می توانید به آنها مراجعه کنید... موفق باشید

سلام
از اینکه اینجا سوال خودمو مطرح میکنم پوزش می خوام، هرچی بیشتر گشتم کمتر پیدا کردم:

واسه وب سایتی که دارم می نویسم ، می خوام از asp.net configuration استفاده کنم و خیلی خودمو درگیر مسایل امنیتی نکنم و این کار را به عهده ویزارد بگذارم
مشکلی که پیش میاد اینه که این ویزارد یه دیتابیس با access تولید میکنه و دیتابیس برنامه من هم sql server هست . در نتیجه یه برنامه دارم با دو تا دیتابیس که یکی از نوع اس کیو ال سرور و دیگری از نوع اکسس هست. حالا می خوام بدونم اصلا در محیط های کاری یه همچین سایتی معقوله ؟ راهی هست که از این ابزار یا مشابه اون استفاده کنم و دیتابیس تولید شده از نوع sql server باشه و اونو در دیتابیس برنامه ادغام کنم که برنامه دیگه 2 تا دیتابیس لازم نداشته باشه. یا security provider رایگانی هست که بشه از اون برای این منظور استفاده کرد؟

یکی از دوستان عزیز لطف کردن و جواب دادن و کتاب هم معرفی کردن ولی جواب ایشون و کتاب معرفی شده برای کسی هست که در سطح متوسط و پیشرفته است ولی من در این زمینه مبتدی هستم و ترجیح میدم فعلا روی یادگیری و تمرین asp.net وقت بگذارم و بعد وارد این ریزه کاریها بشم

از راهنماییهاتون پیشاپیش متشکرم

SQL INJECTION دنیایی برای خودشه.هر چقدر هم فیلترینگ و.... بنویسین.بازم میشه هک کرد بعدش هم هکر به اوون زودیهایی هم که فکر میکنین خسته نمیشه! چیزی که زیاده BUG !.:چشمک:

درسته.موافقم.
اما همین حمله ها از باگ های کوچیک شروع میشه.
حالا من یک کد نوشتم که میاد مقادیری مثل Query String و ورودی های فرم ها رو بررسی میکنه و کاراکتر ها و عبارات خطرناک فیلتر میکنه.

Function killChars(strWords) 

dim badChars 

dim newChars 

badChars = array("select", "drop", ";", "--", "insert",_  

"delete", "xp_", "'") 

newChars = strWords 

for i = 0 to uBound(badChars) 

newChars = replace(newChars, badChars(i), "") 

next 

killChars = newChars 

End Function 

تو این سایت هم آموزش خوبی درباره sqlInjection هست:

http://www.alfa-web.net/EduContent.aspx?EduID=22

جناب مدیر کد شما فکر منم کامل نباشه اگه با کد هگز حمله کنه چی؟

درسته.حق باشماست
به همین دلیل هم من میگم که اینجکشن از باگ های پیش پا افتاده شروع میشه.
یه روش خوب که من اغلب اوقات هم ازش استفاده میکنم اینه که مقدار id رو مثلا فقط با عدد قبول کنید و اگه id غیر عددی بود response.end بزنه و هزاران راه دیگه که دیگه بستگی به خلاقیت و تجربه برنامه نویس داره.

نقل قول:

---

نوشته شده توسط aryaei2000

درسته.حق باشماست
به همین دلیل هم من میگم که اینجکشن از باگ های پیش پا افتاده شروع میشه.
یه روش خوب که من اغلب اوقات هم ازش استفاده میکنم اینه که مقدار id رو مثلا فقط با عدد قبول کنید و اگه id غیر عددی بود response.end بزنه و هزاران راه دیگه که دیگه بستگی به خلاقیت و تجربه برنامه نویس داره.

---

من هم از روش عددی استفاده می کنم که خیلی خوب و کارامد هستش

نقل قول:

---

نوشته شده توسط 3nitro

قدم دوم :خلاصه : یک صفحه ورود نسبتا خوب که معمولا الگوریتم مشخصی هم داره اینه که -->
1)گرفتن یوزرنیم و پسورد از بازدید کننده و فیلتر کردن ' و ; و " و -- و دیگر کاراکترها به وسیله تابع replace
2)تعیین اینکه آیا یوزر نیم و پسورد گرفته شده از بازدید کننده (که صد البته منظورم یوزرنیم و پسورد بعد از اجرای فیلتر و محدود کردن اون) صحیح هست یا نه به وسیله sql و asp .
3)اگه صحیح بود تشکیل session و ارجاع به صفحه اصلی مدیریت و چک شدن session در اون صفحه اصلی و سایر صفحات مدیر برای اینکه یه موقع خدای نکرده هکر مستقیم url رو وارد نکرده باشه .

---

سلام.
شما به این میگید تامین امنیت؟؟؟ اولین نکته در بخش امنیت این هستش که بدونید امنیت مثل یک زنجیره که استقامتش به اندازه استقامت ضعیفترین حلقه زنجیره. دومین نکته ای که باید بدونید اینه که شما نباید بدنبال این باشید که چه کارهایی رو مهاجم نباید انجام بده! شما باید دنبال این باشید که کاربر اجازه انجام چه کاری رو باید داشته باشه. هر چیزی غیر اون، نامعتبره. و الا اینکه فلان Character رو فیلتر کنیم و ... اصلا با اصول SDL سازگار نیست و از بیخ و بن اشکال داره... سومین نکته ای که باید بدونید اطلاع از Session Hijacking هستش و ...

ای بابا... سرم سوت کشید این تاپیک رو دیدم. لطفا کلش رو حذفش کنید، تا کسی بیشتر از این صدمه نبینه! موفق باشید.