واکشی مقادیری که کلاینت به سمت سرور سند میکند امکان پذیر است؟

[intel_amd]

واکشی مقادیری که کلاینت به سمت سرور سند میکند امکان پذیر است؟
هم از طریق http که از داخل winapp کانال میزنیم هم از طریق خود صفحه وب منظورمه که وقتی مقداری به سمت سرور سند میشه آیا میشه توسط برنامه ای مانیتور کرد مقدارشو؟

[us1234]

در ویندوز را نمیدونم ولی در لینوکس ( یا میکروتیک ) ISP ها دیدم در قسمت لاگ کانکشن های squid سایت ها و پارامتر های ارسال شده توسط کاربر ، بسته به کانفیگ همیشه یه تعدادیش وجود دارد .
البته با یک اس اس ال تمام این راه ها بسته میشود .

[intel_amd]

الان با وجود چنین sniffer هائی که به این راحتی میشه ترافیکو مانیتور کرد هک راه دوری نیست ! پس چه کنیم با دیتاهای ارسالیمون چون داخلشون بعضا دیتاهای حیاتی رد و بدل میشه مثل یوزر و پس دیتا بیس ! و ...
در رابطه با این ssl میشه بیشتر بگید؟
من یک کانالهائی با http از داخل winapp به هاست زدم و بعضا یوزر و پس دیتا بیس و پس یوزر و اینها رد و بدل میشه در این کانال و با شنودش همه چیز راحت هک میشه !

[us1234]

الان با وجود چنین sniffer هائی که به این راحتی میشه ترافیکو مانیتور کرد هک راه دوری نیست ! پس چه کنیم با دیتاهای ارسالیمون چون داخلشون بعضا دیتاهای حیاتی رد و بدل میشه مثل یوزر و پس دیتا بیس ! و ...
در رابطه با این ssl میشه بیشتر بگید؟
من یک کانالهائی با http از داخل winapp به هاست زدم و بعضا یوزر و پس دیتا بیس و پس یوزر و اینها رد و بدل میشه در این کانال و با شنودش همه چیز راحت هک میشه !


همانطور که قبلا هم عرض کردم در خصوص ssl تحقیق کنید .
شرکت های معتبری ( مثل کومودو ) وجود دارد که به ازای مبلغ نه چندان زیاد به شما اس اس ال میدهند .
ssl هم به سادگی روی هر نوع هاستی نصب میشود و کارشون کد کردن اطلاعات رد و بدل شده است .

[MMSHFE]

اگه نخواستین از SSL استفاده کنید هم راههای جایگزین (بدون هزینه) هست که البته نمیخوام بگم کلاً بیخیال SSL بشین یا این راهها صددرصد مثل همون کار میکنن و فقط قصدم معرفی تکنیکهای جایگزینه. یکی از این روشها کدگذاری اطلاعات مبادله شده بین کلاینت و سرور بصورت دستیه. مثلاً میتونید با الگوریتم AES و با کلید خصوصی که خودتون میدونید، اطلاعاتی که قراره برای سرور ارسال بشه رو رمزگذاری کنید و بعد در سمت سرور اطلاعات رو دریافت و دوباره با همون کلید رمزگشایی کنید. حتی میتونید برای امنیت بیشتر، در هر درخواست کلید خصوصی رو توسط PHP بصورت تصادفی تولید کنید و توی سشن بگذارین و جواب بعدی درخواست که میاد، با کلیدی که توی سشن هست، رمزگشایی رو انجام بدین.

[eshpilen]

مثلاً میتونید با الگوریتم AES و با کلید خصوصی که خودتون میدونید، اطلاعاتی که قراره برای سرور ارسال بشه رو رمزگذاری کنید و بعد در سمت سرور اطلاعات رو دریافت و دوباره با همون کلید رمزگشایی کنید.
اگر منظورت اینه که بیایم و سمت کلاینت با اون کلید اطلاعات رو قبل از ارسال رمزگذاری کنیم، یعنی طبیعتا کلید هم ابتدا باید از طرف سرور به کلاینت ارسال شده باشه (روی کانال ناامن HTTP)، این روش اصولی و امنی نیست چون بهرحال یک هکر حرفه ای و با انگیزه میتونه کلید رو هم دربیاره. البته این سناریو طبیعتا کمی پیچیده تره و نیاز به زحمت و زمان و انگیزهء بیشتری داره نسبت به اونکه اطلاعات همینطوری بدون رمزگذاری به سرور ارسال بشه، ولی بهرحال امنیت آنچنانی محسوب نمیشه و به همین خاطر بنظرم اغلب ارزش پیاده سازی نداره و از طرف دیگر ضررش اینه که ممکنه یک نوع تصور غلط عمومی و یا توهم امنیت برای خیلی ها ایجاد کنه.
ضمنا در حمله های Active هکر میتونه اصولا کل سیستم رمزنگاری رو با جایگزین کردن کدهای سمت کلاینت مورد نظر خودش از کار بندازه یا دور بزنه و مثلا حتی اگر شما از RSA استفاده کرده باشی و در سمت کلاینت با کلید عمومی اطلاعات رو رمز کنی که در این صورت فقط در سمت سرور و با کلید خصوصی میشه رمزگشایی کرد، بازم امنیت اصولی نداره (ولی این روش در حمله های Passive مقداری جذاب بنظر میاد چون طرف نمیتونه اطلاعات رو حتی با دونستن کلیدی که به کلاینت ارسال میشه رمزگشایی کنه - ولی باید به این محدودیت فنی هم توجه داشت که یک مشکلی که RSA نسبت به AES داره اینه که خیلی سنگین تر و کندتره و این بخصوص ممکنه برای دستگاههای ضعیف مشکل ایجاد کنه).

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

راستی هش کردن پسورد کاربر قبل از ارسال به سرور هم بنظرم ایدهء خوبی باشه و بعضیا انجام میدن (خودم هم در پروژه سیستم رجیستر و لاگین انجام دادم) ولی اینم محدودیت داره و فقط از لو رفتن اصل پسورد جلوگیری میکنه (و نه لاگین بجای کاربر) و همچنین دربرابر حمله های Active کارایی نداره؛ در ضمن اگر پسورد ضعیف باشه همون هش هم ممکنه Brute-force بشه و اصل پسورد کشف بشه.

ضمنا یه ایدهء مخوف هم الان به ذهنم رسید که البته باید بیشتر روش فکر کنم و اگر چیز جالبی بود شاید بعدا منتشر کنم :لبخند:
البته این ایده های مخوف که به ذهن من میاد زیاد عجیب نیست و گاهی شاید حتی مال خودم هم نیست ولی یادم نیست چون اینقدر تاحالا مقاله و مطالب راجع به امنیت و رمزنگاری و ایده های جالب و پیچیده خوندم که توی ذهنم کلی چیز میز و ارتباط در این زمینه همینطور اینور و اونور ریخته و وقتی به چیزی فکر میکنم در یک زمان کوتاه کلیش میاد رو و گاهی چند ایده همزمان به ذهنم میرسه!

[MMSHFE]

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

[eshpilen]

میشه همون کلید خصوصی رو هم با یک کلید عمومی دیگه که فقط خود کلاینت و سرور میدونن رمزنگاری کرد و فرستاد.
اگر شما راهی داشته باشی که بشه کلیدی رو فقط سرور و کلاینت بدونن که دیگه قضیه حله بنظرم و مشکل جدی ای در کار نیست و میتونی از همون رمزنگاری AES استفاده کنی.
مشکل همیشه اینه که نمیشه همینطوری از قبل بین کلاینت و سرور یک کلید محرمانه وجود داشته باشه بدون اینکه از طریق کانال ناامنی ارسال شده باشه (البته SSL برای حل همین مشکل بوجود آمد). مگر اینکه کلاینت و سرور قبلا یک هماهنگی و رابطهء اختصاصی داشته بوده باشن؛ مثلا خودمون کلید رو دستی در کلاینت ها نصب کرده باشیم.
البته یخورده مبهم گفتی دقیقا متوجه نشدم میخوای چکار کنی و چرا.

[MMSHFE]

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

[eshpilen]

ببین نمیخوام بگم روش کاملاً امنیه. فقط بهتر از هیچیه. ما توی یکی از پروژه هامون اومدیم یک کلید عمومی گذاشتیم که فقط کلاینت و سرور میدونستن و درنتیجه ازطریق شبکه مبادله نمیشد. این کلید هم حالا یا هارد کد میشد تو کلاینت یا با وب سرویس و یکسری چیزای دیگه در اولین درخواست به سرور دریافت میشد و توی کوکی ذخیره میشد. در مرحله بعد یک کلید خصوصی در هر درخواست ساخته میشد و توی سشن میگذاشتیم و این کلید خصوصی رو با کلید عمومی رمزگذاری و به کلاینت ارسال میکردیم. از اینجا به بعد تمام اطلاعات با این کلیدهای خصوصی رمزگذاری میشد و برای سرور ارسال میشد و سرور هم از توی سشن خودش میخوند که چه کلید خصوصی رو در آخرین درخواست اون کلاینت ست کرده و جوابهای کلاینت رو با اون کلید رمزگشایی و پردازش میکرد.
آره دیگه منم گفتم که اگر بتونید از طریق کانال جانبی دیگری یک کلید محرمانه بین کلاینت و سرور داشته باشید میشه یه کارهایی کرد. در واقع در برنامه های دسکتاپ میشه به این شکل ارتباطات کاملا امنی رو پیاده سازی کرد، ولی در برنامه های تحت مرورگر چون سورس خود برنامه هر بار از سمت سرور میاد و بنابراین یک هکر Active میتونه اون رو دستکاری کنه، امنیت کاملی بدست نمیاد چون هکر میتونه سورس برنامه رو دستکاری کنه و رمزنگاری رو به کلی غیرفعال کنه یا دور بزنه.


یا هارد کد میشد تو کلاینت یا با وب سرویس و یکسری چیزای دیگه در اولین درخواست به سرور دریافت میشد و توی کوکی ذخیره میشد.
بنظرم شکل هاردکد شده امنیتش خیلی بیشتره. اون مدل که میگید در اولین درخواست به سرور دریافت میشد ضعیف تره بخاطر اینکه 1) در همون اولین درخواست ممکنه کلید سرقت بشه، و 2) مشکل به مراتب گنده ترش اینه که کوکی توسط مرورگر در هر درخواست دوباره به سرور ارسال میشه و بنابراین کلید مدام داره در کانال ناامن ارسال میشه. البته شاید برای این مورد فکری کرده بوده باشید :متفکر:

[MMSHFE]

وقتی تنها کاربرد کلید عمومی، رمزنگاری کلید خصوصیه و کلید خصوصی هم برای هر کلاینت توی هر درخواست دوباره تولید میشه، فکر نمیکنم تبادل کلید عمومی (اسمش روشه - عمومیه و زیاد نباید روش تکیه کرد) ازطریق کانال ناامن مشکل زیادی ایجاد کنه. درهرحال ما توی اون پروژه هارد کد رو مورد استفاده قرار دادیم منتها همون کلید عمومی هم در اولین درخواست کلاینت توسط سرور تولید میشد و توی کدهای JS درج میشد و توی سشن هم ذخیره میکردیم و از اون به بعد هربار کلید خصوصی با کلید عمومی رمزگذاری و ارسال میشد و بقیه ماجرا همونطوری که توضیح دادم ادامه پیدا میکرد. اینطوری کلید عمومی هر کلاینت هم با کلاینت دیگه متفاوت بود و درنتیجه زیاد بدردش نمیخورد چون با ترکیب IP و Agent و... تولید شده بود و کم پیش میاد که همه این موارد رو با هم بشه جعل کرد یا کسی کلاً اطلاع داشته باشه که چه مواردی توی تولید کلید عمومی دخیل بوده که بخواد همه رو جعل کنه و حتی بدونه اطلاعات کلاینت مربوطه چی بوده که بخواد جعل کنه.

[eshpilen]

وقتی تنها کاربرد کلید عمومی، رمزنگاری کلید خصوصیه و کلید خصوصی هم برای هر کلاینت توی هر درخواست دوباره تولید میشه، فکر نمیکنم تبادل کلید عمومی (اسمش روشه - عمومیه و زیاد نباید روش تکیه کرد) ازطریق کانال ناامن مشکل زیادی ایجاد کنه.
توضیحات شما برام بیش از حد مبهمه و نیاز به تشریح کامل و دقیق فنی الگوریتم و اصطلاحات استفاده شده داره تا بشه تحلیل امنیتی روش داشت و نظری درموردش داد.
کلید عمومی و خصوصی رو بعضی جاها به معانی متفاوت استفاده میکنن. آیا منظور شما از عمومی و خصوصی، زوج کلید مورد استفاده در رمزنگاری RSA است؟

[MMSHFE]

ما توی الگوریتم خودمون کلید عمومی رو کلیدی تعریف کردیم که برای هر کلاینت در طول تمام درخواستهاش در طی سشن یکسان و ثابته (برای جلوگیری از حملاتی شبیه Session Fixation و Hijacking) و کلید خصوصی هم کلیدی بود که در هر درخواست عوض میشد (تا جلوی CSRF و امثال اون رو بگیریم).

[intel_amd]

دوستان یک حالتی به شکل زیر برام پیش اومده که شدیدا امنیت پائین آورده به نظرتون این با ssl یا encryption decryption دیتا سمت کلاینت و سرور درست میشه؟
یک فایل به شکل xml در هاست وجود داره که یوزر پس دیتابیسم توشه و بسته به سیستم مجبورم این فایل از کلاینت بخونم و یوزر پس دیتا بیسو با http بفرستم برای هاست
خود فایل xml انکد کردم و سمت کلاینت موقع خوندن دیکد میکنم میخونم اما یوزر پس دیتا بیسو بدون انکد با http میفرستم برای هاست

[us1234]

دوستان یک حالتی به شکل زیر برام پیش اومده که شدیدا امنیت پائین آورده به نظرتون این با ssl یا encryption decryption دیتا سمت کلاینت و سرور درست میشه؟
یک فایل به شکل xml در هاست وجود داره که یوزر پس دیتابیسم توشه و بسته به سیستم مجبورم این فایل از کلاینت بخونم و یوزر پس دیتا بیسو با http بفرستم برای هاست
خود فایل xml انکد کردم و سمت کلاینت موقع خوندن دیکد میکنم میخونم اما یوزر پس دیتا بیسو بدون انکد با http میفرستم برای هاست

باید کلیات هدفتون را بگید . این روش را برای چی استفاده می کنید ؟
در کل اگر به هر روشی عملکرد دیکد کردن سمت کلاینت فاش شود کل اطلاعات ارسالی شما در دسترس است . ( حتی اگر با ssl مبادله کرده باشید ! )

کامل شرح دهید تا بهترین روش پیاده سازی با وب سرویس ارائه شود .