জাভাস্ক্রিপ্ট হ্যাক করা কত সহজ (একটি ব্রাউজারে)?

Question

আমার প্রশ্নটি জাভাস্ক্রিপ্ট সুরক্ষার সাথে সম্পর্কিত।

এমন কোনও প্রমাণীকরণ সিস্টেমের কল্পনা করুন যেখানে আপনি ব্যাকবোন বা অ্যাঙ্গুলারজেএস এর মতো একটি জাভাস্ক্রিপ্ট কাঠামো ব্যবহার করছেন এবং আপনার নিরাপদ সমাপ্তিগুলি দরকার। এটি কোনও সমস্যা নয়, কারণ সার্ভারের সর্বদা সর্বশেষ শব্দ থাকে এবং আপনি যা চান তা করার জন্য আপনি অনুমোদিত কিনা তা পরীক্ষা করবে।

তবে আপনি যদি সার্ভারকে জড়িত না করে একটু সুরক্ষা প্রয়োজন? এটা কি সম্ভব?

উদাহরণস্বরূপ, বলুন যে আপনি একটি ক্লায়েন্ট-সাইড রাউটিং সিস্টেম পেয়েছেন এবং আপনি চাইছেন লগ-ইন করা ব্যবহারকারীদের জন্য একটি কংক্রিটের রুট সুরক্ষিত হোক। সুতরাং আপনি সুরক্ষিত রুটগুলিকে জিজ্ঞাসা করছেন যে আপনি সুরক্ষিত রুটগুলি দেখার অনুমতি দিচ্ছেন এবং আপনি এগিয়ে যান। সমস্যাটি হ'ল আপনি যখন সার্ভারটি পিং করেন, তখন আপনি প্রতিক্রিয়াটি একটি ভেরিয়েবলে সংরক্ষণ করেন, তাই পরের বার আপনি কোনও ব্যক্তিগত রুটে গেলে এটি পরীক্ষা করে দেখবে যে আপনি ইতিমধ্যে লগ ইন (সার্ভারে কোনও পিং নেই) এবং নির্ভর করে প্রতিক্রিয়া এটি যেতে হবে বা না।

কোনও ব্যবহারকারীর পক্ষে সেই পরিবর্তনশীলটি সংশোধন করা এবং অ্যাক্সেস পাওয়া কত সহজ?

আমার সুরক্ষা (এবং জাভাস্ক্রিপ্ট) জ্ঞান দুর্দান্ত নয়। তবে যদি কোনও ভেরিয়েবল বৈশ্বিক পরিমণ্ডলে না থাকে এবং একটি মডিউল প্যাটার্নের ব্যক্তিগত অংশে থাকে যা কেবল গেটর রয়েছে তবে সেটারও নেই, সে ক্ষেত্রেও আপনি কী জিনিসটি হ্যাক করতে পারেন?

Comments

এই সব দীর্ঘ উত্তর। সংক্ষেপে, আপনাকে শিরোনামের জবাব দিতে, "খুব হ্যাকযোগ্য"। আপনার প্রথম 2 টি প্রশ্নের উত্তর একে অপরের সাথে, "সার্ভার ছাড়াই আপনি সুরক্ষা হারিয়েছেন" এবং& "না" উত্তর দেওয়ার জন্য। 3 য়, "খুব সহজ" এবং শেষ পর্যন্ত "হ্যাঁ, স্বাচ্ছন্দ্যে" উত্তর দেওয়ার জন্য। এই নাও. সমস্ত প্রশ্নের উত্তর। : পি

— SpYk3HH

প্রধান উদাহরণ, যে কোনও ওয়েব পৃষ্ঠায় jQuery যুক্ত করার বিষয়ে আমার ব্লগ পোস্টটি দেখুন। spyk3lc.blogspot.com/2013/05/… এখন, তরুণ পাদওয়ান , এগিয়ে যান এবং এটি চেষ্টা করুন। এটি ইতিমধ্যে নেই এমন যে কোনও সাইটে jQuery যুক্ত করা ঠিক কত সহজ তা দেখুন, তারপরে জাভাস্ক্রিপ্টের দীর্ঘ লাইনগুলি না দিয়ে দৃষ্টির কোনও অংশ খুব সহজেই ব্যবহার করতে jquery ব্যবহার করুন। পরিস্ফুটন!

— SpYk3HH

একবার, কোনও ডোমেন নামের জন্য নিবন্ধকরণ করার সময়, ফোন নম্বরটি একটি প্রয়োজনীয় ক্ষেত্র ছিল, তবে এটি কেবল জাভাস্ক্রিপ্টে প্রয়োগ করা হয়েছিল - সার্ভারের দিক থেকে নয়। সুতরাং, আমি এটি একটি ফাংশন (ফায়ারব্যাগ ব্যবহার করে) এবং ভয়েলির নতুন সংজ্ঞা দিয়ে অক্ষম করেছি! তাদের কাছে আমার ফোন নম্বর নেই।

— ইজকাটা

manipulate any part of the sight without long lines সাইট বনাম দর্শন

— এমপ্লুঞ্জন

পেশাদার ওয়েব প্রোগ্রামারদের এ জাতীয় জিনিসটি সঠিকভাবে পাওয়া দরকার। অনুগ্রহ. এটা একটা ব্যাকরণ নাৎসি জিনিস :) চেয়ে বেশি বিড়ম্বনা plus.google.com/u/0/+MonaNomura/posts/h9ywDhfEYxT

— mplungjan

Answer 1

এটি পড়ার আগে দয়া করে জোয়াকিমের উত্তরটি পড়ুন। তিনি ক্লায়েন্ট-পক্ষের দুর্বলতার পিছনে সাধারণ কারণগুলি coversেকে রাখেন। এখন, আপনি কীভাবে এই সমস্যাটি পেতে পারেন তার পরামর্শের জন্য ...

প্রতিটি অনুরোধে ম্যানুয়ালি সার্ভারের সাথে প্রমাণীকরণ না করে ক্লায়েন্ট-সার্ভার যোগাযোগের জন্য একটি সুরক্ষিত স্কিম:

আপনি এখনও সার্ভারকে শেষ কথা বলতে দিচ্ছেন, এবং ক্লায়েন্ট যা বলেছে তা সার্ভারকে এখনও যাচাই করতে হবে, তবে এটি স্বচ্ছভাবে ঘটে।

ম্যান-ইন-মধ্য-আক্রমণ (MITMA) রোধে এইচটিটিপিএস প্রোটোকল ধরে নিন prot

• ক্লায়েন্টটি প্রথমবার সার্ভারের সাথে হাত মিলিয়ে দেয় এবং সার্ভার ক্লায়েন্টের জন্য একটি সর্বজনীন কী উত্পন্ন করে এবং একটি বেসরকারীকে অসমমিতিক এনক্রিপশন স্কিম ব্যবহার করে রাখে। ক্লায়েন্ট সার্ভারের "পাবলিক" কী স্থানীয় স্টোরেজে সঞ্চয় করে, কোনও সুরক্ষিত পাসওয়ার্ড দিয়ে এনক্রিপ্ট করে আপনি কোথাও সংরক্ষণ করেন না।

• ক্লায়েন্টটি এখন অফলাইন। ক্লায়েন্ট বিশ্বস্ত ক্রিয়া সম্পাদন করতে চায়। ক্লায়েন্ট তার পাসওয়ার্ড প্রবেশ করে এবং সার্ভারের পাবলিক কীটি ধরে bs

• যে ডেটা তার জ্ঞানের ভিত্তিতে এখন ক্লায়েন্ট সঞ্চালিত কর্ম, এবং ক্লায়েন্ট যে কর্ম এটা সার্ভারের পাবলিক কী দিয়ে সঞ্চালিত এনক্রিপ্ট যে ক্লায়েন্টের জন্য ।

• ক্লায়েন্ট অনলাইনে থাকলে ক্লায়েন্ট তার ক্লায়েন্ট আইডি প্রেরণ করে এবং ক্লায়েন্টটি সম্পাদিত সমস্ত ক্রিয়াকলাপ সার্ভারের সর্বজনীন কী সহ এনক্রিপ্ট করা সার্ভারে প্রেরণ করা হয়।

• সার্ভারটি ক্রিয়াগুলি ডিক্রিপ্ট করে এবং যদি তারা সঠিক ফর্ম্যাটে থাকে তবে এটি নির্ভর করে যে তারা ক্লায়েন্টের উদ্ভব হয়েছিল।

বিঃদ্রঃ:

• আপনি ক্লায়েন্টের পাসওয়ার্ড কোথাও সংরক্ষণ করতে পারবেন না, অন্যথায় আক্রমণকারী কীটি আনতে সক্ষম হবে এবং ক্রিয়াগুলি তার নিজের হিসাবে সাইন করতে সক্ষম হবে। এই স্কিমটির সুরক্ষা ক্লায়েন্টের জন্য সার্ভারটি যে কী দ্বারা তৈরি করা হয়েছে তার সম্পূর্ণতার উপর নির্ভর করে। এই কীটি জিজ্ঞাসা করার সময় ক্লায়েন্টটিকে এখনও সার্ভারের সাথে প্রমাণীকরণের প্রয়োজন হবে।

• আপনি এখনও সুরক্ষার জন্য সার্ভারের উপর নির্ভর করছেন এবং ক্লায়েন্ট নয়। ক্লায়েন্ট আপনাকে সম্পাদিত প্রতিটি ক্রিয়াকলাপ আপনাকে অবশ্যই সার্ভারে যাচাই করতে হবে ।

• ওয়েব কর্মীদের মধ্যে বাহ্যিক স্ক্রিপ্টগুলি চালানো সম্ভব । আপনার কাছে থাকা প্রতিটি জেএসএনপি অনুরোধটি মনে রাখবেন এখন অনেক বড় সুরক্ষা সমস্যা। আপনাকে সমস্ত মূল্যে কীটি রক্ষা করতে হবে। একবার আপনি এটি হারাতে পারলে, একজন আক্রমণকারী ব্যবহারকারীর ছদ্মবেশ তৈরি করতে পারে।

• এটি আপনার চাহিদা পূরণ করে যে 'সার্ভারে কোনও পিং' করা হয় না। কোনও আক্রমণকারী জালযুক্ত ডেটার সাথে কীটি না জানলে কেবল কোনও HTTP অনুরোধটি অনুকরণ করতে পারে না।

• জোয়াকিমের উত্তর এখনও সঠিক । আপনি আসলে, এখনও, সমস্ত প্রমাণীকরণ করণ সার্ভারে । আপনি এখানে সংরক্ষণ করেছেন কেবলমাত্র প্রতিটি সময় সার্ভারের সাথে পাসওয়ার্ড বৈধকরণের প্রয়োজন। আপনি এখন প্রতিশ্রুতিবদ্ধ করতে চাইলে সার্ভারকে জড়িত করতে বা আপডেট করা ডেটা টানতে হবে। আমরা এখানে যা করেছি তা হ'ল ক্লায়েন্টের পক্ষে একটি বিশ্বাসযোগ্য কীটি সংরক্ষণ করা এবং ক্লায়েন্টটিকে এটি পুনরায় বৈধতা দিতে হবে।

• এটি একক পৃষ্ঠাগুলির অ্যাপ্লিকেশনগুলির জন্য একটি দুর্দান্ত সাধারণ স্কিম (উদাহরণস্বরূপ, AngularJS সহ)।

• আমি সার্ভারের সর্বজনীন কী "সর্বজনীন" কারণ কি উপায়ে যে ভালো স্কিম এর কল আরএসএ , কিন্তু এটা স্কিম আসলে সংবেদনশীল তথ্য রয়েছে এবং সুরক্ষিত হবে।

• আমি পাসওয়ার্ডটি মেমরির কোথাও রাখব না। আমি যখনই অফলাইন কোড চালানো শুরু করি তখনই আমি তার / তার 'অফলাইন' পাসওয়ার্ডটি ব্যবহারকারীকে জমা করিয়ে দেব।

• আপনার নিজের ক্রিপ্টোগ্রাফি রোল করবেন না - প্রমাণীকরণের জন্য স্ট্যানফোর্ডের মতো পরিচিত গ্রন্থাগার ব্যবহার করুন।

• এই পরামর্শটি যেমন নিন তেমন করুন । আপনি এই ধরণের প্রমাণীকরণকে আসল বিশ্বের ব্যবসায়-সমালোচনামূলক অ্যাপ্লিকেশনটিতে রোল করার আগে কোনও সুরক্ষা বিশেষজ্ঞের পরামর্শ নিন । এটি একটি গুরুতর সমস্যা যা উভয়ই বেদনাদায়ক এবং ভুল হওয়া সহজ।

এটি সমালোচনা যে অন্য কোনও স্ক্রিপ্টের পৃষ্ঠাটিতে অ্যাক্সেস নেই। এর অর্থ আপনি কেবলমাত্র ওয়েব কর্মীদের সাথে বাহ্যিক স্ক্রিপ্টগুলিকে মঞ্জুরি দিন। আপনি ব্যবহারকারীর প্রবেশের সময় আপনার অন্য পাসওয়ার্ডটিকে বাধা দিতে পারে এমন কোনও বাহ্যিক স্ক্রিপ্টগুলিতে বিশ্বাস করতে পারবেন না।

একটি ব্যবহার করুন promptএবং না একটি ইনলাইন পাসওয়ার্ড ক্ষেত্রের যদি তুমি না সম্পূর্ণরূপে নিশ্চিত এবং মুলতবি না তার মৃত্যুদন্ড না (যে, এটি করা উচিত একটি বিন্দু যেখানে ঘটনা শুধুমাত্র সিঙ্ক কোডে এটিতে অ্যাক্সেস কিন্তু না আছে লাইভ)। এবং পাসওয়ার্ডটি আসলে কোনও ভেরিয়েলেলে সংরক্ষণ করবেন না - আবার, এটি কেবল তখনই কাজ করে যদি আপনি বিশ্বাস করেন যে ব্যবহারকারীর কম্পিউটার আপোস না করা হয়েছে (যদিও এটি কোনও সার্ভারের বিরুদ্ধেও বৈধতার জন্য সত্য)।

আমি আবার যুক্ত করতে চাই যে আমরা এখনও ক্লায়েন্টকে বিশ্বাস করি না । আপনি একা ক্লায়েন্টকে বিশ্বাস করতে পারবেন না এবং আমি মনে করি জোয়াকিমের উত্তর এটি নখ করে দিয়েছে। কাজ শুরু করার আগে আমরা কেবল সার্ভারটি পিং না করার সুবিধার্থে পেয়েছি।

সম্পর্কিত উপাদান:

• শংসাপত্র বনাম ব্যবহারকারীর নাম + পাসওয়ার্ড ।
• কেন আমরা ক্লায়েন্ট পক্ষের মাধ্যমে সুরক্ষা করতে পারি না?
• আপনার নিজের ক্রিপ্টো রোল করবেন না।
• ক্রিপ্টো অপারেশনের জন্য জেএসকে সুরক্ষিত করা সম্পর্কিত সম্পর্কিত আলোচনা

Comments

"আপনার নিজের ক্রিপ্টো রোল করবেন না" প্রোটোকলগুলিতে ঠিক ততটুকু প্রযোজ্য যেমন এটি আরও বেশি না হলেও কারণ মানুষ সাধারণত নিজের আদিম তৈরির জন্য যথেষ্ট বোকা নয়, তারা মনে করে যে তারা একটি প্রোটোকল তৈরি করতে পারে যা ঠিক আছে । আরএসএ কেন এখানে প্রয়োজনীয় তা আমিও দেখতে পাচ্ছি না। যেহেতু আপনি এইচটিটিপিএস ব্যবহার করছেন, কেন কেবল একটি 16-32 বাইট ভাগ করা গোপন তৈরি করে না এবং ভবিষ্যতের অনুরোধগুলির সাথে প্রেরণ করা প্রয়োজন? অবশ্যই, আপনি যদি এটি করেন তবে স্ট্রিংয়ের সময়-আক্রমণকারী সমতা পরীক্ষা করার বিষয়টি নিশ্চিত করুন ...

— রেড

+1 @ রেড হ্যাঁ, আমি সম্প্রতি এই সম্পর্কে কিছুটা বিশেষজ্ঞের সাথে এই সম্পর্কে আলোচনা করেছি। আমি প্রায় আঞ্চলিক স্কিমটি এখানে রবিন আইআইআরসি দ্বারা শিখেছি এমন একটি প্রোটোকলের উপর ভিত্তি করে তৈরি করেছি তবে কমপক্ষে আমি সুনির্দিষ্টতার সন্ধান করতে পারি না (এবং কেন এই ক্ষেত্রে অসমমিতিক এনক্রিপশন প্রয়োজন তা উদাহরণস্বরূপ প্রমাণ করতে পারি)। প্রথমে সুরক্ষা বিশেষজ্ঞের পরামর্শ না নিয়ে এই উত্তরে প্রস্তাবিত স্কিমটি ব্যবহার করবেন না । আমি এই পদ্ধতিটি বেশ কয়েকটি স্থানে ব্যবহৃত দেখেছি, তবে বাস্তবে এটির অর্থ খুব কম, যদি কিছু থাকে। আমি এটি বাড়ানোর জন্য উত্তরটি সম্পাদনা করেছি।

— বেনিয়ামিন গ্রুইনবাউম

প্রম্পট ব্যবহার করা সামান্য সুরক্ষা যুক্ত করে। একজন আক্রমণকারী window.promptপাস বাক্যাংশটি বাধা দিতে বা একটি নিজস্ব প্রম্পট (সম্ভবত একটি আইফ্রেমের মধ্যেই!) চালু করতে পদ্ধতিটিকে ওভাররাইড করতে পারে। একটি পাসওয়ার্ড ক্ষেত্রে একটি অতিরিক্ত সুবিধা রয়েছে: অক্ষরগুলি দেখানো হয় না।

— রব ডব্লু

@ রবডাব্লু, পৃষ্ঠাটি আপোষ করে থাকলে অবশ্যই এই পুরো পরিকল্পনাটি মূল্যহীন। আক্রমণকারীটির যদি পেজটিতে জাভাস্ক্রিপ্ট চালাতে অ্যাক্সেস থাকে তবে আমরা স্ক্রু করেছি। প্রম্পটের পিছনে ধারণাটি ছিল যে এটি ব্লক করা হচ্ছে তবে আপনি সঠিক, এটি যে কোনও সুরক্ষা সুবিধা দেয় তা সন্দেহজনক। তালিকার শেষ লিঙ্কটি দেখুন।

— বেনিয়ামিন গ্রুইনবাউম

সবার আগে। দুর্দান্ত উত্তর, আমি মনে করি যে আমি অন্য কিছু চাইতে পারি না। অন্যদিকে, আমি আমার জন্য পোষ্য প্রকল্পগুলি করতে চেয়েছিলাম (এবং অবশ্যই এটি কে ব্যবহার করতে চায়) এবং সম্ভবত এটি ওভারকিল (বা সম্ভবত নয়)। আমি বোঝাতে চাইছি, আমি গুরুতর কিছু করতে চাই না এবং আমি আশঙ্কা করি যে আপনি যে ধরণের লেখককে ব্যাখ্যা করেছেন আমি তা জানাতে পারি না, জ্ঞানের অভাব আছে। আমি মনে করি আমি একটি সাধারণ 401 চেক রোল করব বা আমার যদি কোনও অনুরোধ না থাকে, আমি প্রতিবার যখন এই ধরণের রুটগুলি অ্যাক্সেস করি তখনই আমি সার্ভারটি পিং করে দিই। অথথ টোকেনও একটি বিকল্প (এবং আপনি এখানে AFAIK ব্যাখ্যা করেছেন তার সাথে সম্পর্কিত সম্ভবত নিকটতম জিনিস)। আপনাকে ধন্যবাদ :)

— রড্রিগেজ

Answer 2

এটি সহজ: যে কোনও সুরক্ষা প্রক্রিয়া যা ক্লায়েন্টের উপর নির্ভর করে কেবলমাত্র আপনি যা করতে বলছেন তা করার জন্য আপস করা যেতে পারে যখন কোনও আক্রমণকারীর ক্লায়েন্টের নিয়ন্ত্রণ থাকে।

আপনি করতে পারেন ক্লায়েন্টের সুরক্ষা যাচাইগুলি আছে, কিন্তু শুধুমাত্র কার্যকরভাবে একটি "ক্যাশে" (এড়াতে সার্ভারে একটি ব্যয়বহুল যাতায়াত উপার্জন যদি ক্লায়েন্ট ইতিমধ্যে জানে যে উত্তর "না" হবে) হিসেবে কাজ করে।

আপনি যদি কোনও সেট ব্যবহারকারীদের কাছ থেকে তথ্য রাখতে চান তবে নিশ্চিত হয়ে নিন যে সেই ব্যবহারকারীদের ক্লায়েন্ট কখনই সেই তথ্যটি না পেয়ে। আপনি যদি সেই "গোপনীয় তথ্য" নির্দেশাবলীর সাথে একসাথে প্রেরণ করেন "তবে দয়া করে এটি প্রদর্শন করবেন না," সেই অনুরোধটি যাচাই করে এমন কোডটি অক্ষম করা তুচ্ছ হয়ে উঠবে।

আপনি দেখতে পাচ্ছেন, এই উত্তরটিতে সত্যিই কোনও জাভাস্ক্রিপ্ট / ব্রাউজারের নির্দিষ্টকরণের উল্লেখ নেই। কারণ এই ধারণাটি একই, আপনার ক্লায়েন্ট কী তা বিবেচনা করে না। এটি সত্যিকার অর্থে মোটেই গুরুত্বপূর্ণ নয় যে এটি চর্বিযুক্ত ক্লায়েন্ট (traditionalতিহ্যবাহী ক্লায়েন্ট / সার্ভার অ্যাপ), একটি পুরাতন-স্কুল ওয়েব অ্যাপ্লিকেশন, বা বিস্তৃত ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্ট সহ একটি একক পৃষ্ঠা-অ্যাপ্লিকেশন।

আপনার ডেটা সার্ভারটি ছেড়ে যাওয়ার পরে, আপনাকে অবশ্যই ধরে নিতে হবে যে কোনও আক্রমণকারীর এতে সম্পূর্ণ অ্যাক্সেস রয়েছে।

Comments

ধন্যবাদ. আপনি যদি এটি আরও কিছুটা ব্যাখ্যা করতে পারেন তবে সুন্দর হবে, আমার সুরক্ষা জ্ঞানটি তেমন ভাল নয় এবং আমি যে অংশটি বুঝতে পারি তা হ'ল আমি ভুল: পি। আপনি যখন ক্যাশিংয়ের কথা বলবেন, সার্ভার যখন না বলে তখন কেবল ক্যাশে হবে? মানে, যদি সার্ভার একবার হ্যাঁ বলে, আপনি এটি ক্যাশে করতে পারবেন না, তাই না?

— যিশু রদ্রিগেজ

আমি কেবল এটি যুক্ত করতে চাই যে ব্রাউজারে ক্লোজার ভেরিয়েবলগুলি অ্যাক্সেস করা সম্ভব (আপনার উল্লিখিত মডিউল প্যাটার্নের মতো), বিশেষত একটি ডিবাগার দিয়ে :)

— বেনজামিন গ্রুইনবাউম

@ বেনজামিন গ্রুয়েনবাউম: জেএস-বিষয়গুলির দিকে মনোযোগ নিবদ্ধ করে এমন উত্তরে এটির বর্ধন করতে দ্বিধা বোধ করুন। আমি এখানে কেবলমাত্র উচ্চ-স্তরের, প্রযুক্তি-অজ্ঞাব্য ওভারভিউ দিয়েছি। জেএসে ফোকাস করা একটি উত্তরও দুর্দান্ত হবে!

— জোছিম সৌর

সুতরাং সংক্ষেপে, কিছু তথ্য / রুট / জাভাস্ক্রিপ্ট ভেরিয়েবলের উপর নির্ভর করে যা কিছু অ্যাক্সেসযোগ্য তা কোনও অবস্থাতেই নিরাপদ হবে না কারণ আপনি সেই ব্যক্তিগত স্টাফটিতে অ্যাক্সেস করার জন্য যা প্রয়োজন তা বলতে সহজেই আপনি সেই পরিবর্তনশীলটি পরিবর্তন করতে পারবেন।

— যিশু রদ্রিগেজ

@ জোয়াচিমসৌর আমার মনে হয় যে আপনি এই প্রশ্নটির বিন্দুটি মিস করবেন যা আপনি সুন্দরভাবে পেরেক দিয়েছিলেন। ক্লায়েন্ট কী সুরক্ষা গ্রহণ করে তা নির্বিশেষে, যোগাযোগের সাথে আপস করা সম্ভব । আপনি জাভাস্ক্রিপ্টে খুব শক্ত প্রমাণীকরণ সিস্টেম তৈরি করতে পারেন তবে আপনি যখন অন্য কোনও ক্লায়েন্টকেও সত্যের উত্স হিসাবে বিবেচনা করেন এমন কোনও সার্ভারের সাথে যোগাযোগ প্রবেশ করেন তখন এই মুহুর্তের কোনও মূল্য নেই। উত্স কোড সমস্ত ক্লায়েন্ট পক্ষের কাছে প্রেরণ করা হয়েছে, একটি স্মার্ট আক্রমণকারী কেবল এটি পড়তে পারে এবং সার্ভারে একটি HTTP অনুরোধ অনুকরণ করতে পারে। সার্ভারে বৈধতা না থাকলে ক্লায়েন্ট থেকে উদ্ভূত যে কোনওটিকে অবশ্যই অবিশ্বস্ত হিসাবে গণ্য করতে হবে।

— বেনিয়ামিন গ্রুইনবাউম

Answer 3

গেমিং সম্প্রদায়ের একটি প্রবাদ আছে: " ক্লায়েন্ট শত্রুর হাতে"। সার্ভারের মতো সুরক্ষিত অঞ্চলের বাইরে যে কোনও কোড চলমান, তা দুর্বল। সবচেয়ে মৌলিক দৃশ্যে প্রথম স্থানে চালিত না হওয়ার আশঙ্কা actually এটি আপনার" সুরক্ষা কোড "চালানোর ক্লায়েন্টের সিদ্ধান্ত এবং ব্যবহারকারীর পক্ষে কেবল "অপ্ট আউট" করুন native স্থানীয় কোড সহ আপনার কমপক্ষে একটি অ্যাসেমব্লিতে বিভ্রান্তির একটি সুরক্ষা এবং সুরক্ষার অতিরিক্ত স্তর রয়েছে যে কোনও আক্রমণকারীকে এই কৌশলটি পরিচালনা করার জন্য একটি ভাল প্রোগ্রামার হওয়া দরকার, জেএস সাধারণত অবারিত এবং সরল পাঠ হিসাবে আসে। আপনাকে আক্রমণ করার জন্য যা যা করা দরকার তা হ'ল প্রক্সি সার্ভার এবং একটি পাঠ্য সম্পাদকের মতো আধ্যাত্মিক সরঞ্জাম The আক্রমণকারীকে এখনও প্রোগ্রামিং সম্পর্কিত একটি নির্দিষ্ট স্তরের শিক্ষার প্রয়োজন হবে তবে কোনও এক্সিকিউটেবল কোড ইনজেকশন দেওয়ার চেয়ে কোনও পাঠ্যপদর্শক ব্যবহার করে স্ক্রিপ্ট পরিবর্তন করা সহজ।

Comments

অ্যাসেম্বলি কোনও

— অবহেলা

@ মিনিবিল: যদিও একজন মধ্যপন্থী অভিজ্ঞ আক্রমণকারীকে এসেম্বলড কোড নিয়ে কোনও সমস্যা হবে না, তবে এটি একটি খুব বেসিক হাই-পাস ফিল্টার সরবরাহ করবে। (হায় হায়, এটি একাডেমিক, কারণ স্ক্রিপ্টের

— কৌতুকগুলি ওপেনের দৃশ্যের

Answer 4

এটি জাভাস্ক্রিপ্ট হ্যাক করার প্রশ্ন নয়। আমি যদি আপনার অ্যাপ্লিকেশনটিতে আক্রমণ করতে চাইতাম তবে আমি একটি ব্যক্তিগত প্রক্সি ব্যবহার করব যা আমাকে ট্র্যাফিক ক্যাপচার, সংশোধন এবং পুনরায় খেলতে দেয়। আপনার প্রস্তাবিত সুরক্ষা স্কিমটির বিরুদ্ধে কোনও সুরক্ষা নেই বলে মনে হচ্ছে।

Answer 5

কৌণিক সম্পর্কে বিশেষভাবে বলা:

কোনও রুট ক্লায়েন্টের পক্ষের সুরক্ষা কেবল উপস্থিত নেই। এমনকি আপনি যদি সেই রুটে একটি বোতাম 'লুকিয়ে' রাখেন তবে ব্যবহারকারী সর্বদা এটি টাইপ করতে পারে, অ্যাংুলার অভিযোগ করবে, তবে ক্লায়েন্টটি তার চারপাশে কোড করতে পারে।

এক পর্যায়ে আপনার নিয়ামক আপনার ভিউটি রেন্ডার করার জন্য প্রয়োজনীয় ডেটার জন্য আপনার সার্ভারকে জিজ্ঞাসা করতে চলেছে, যদি ব্যবহারকারী সেই ডেটা অ্যাক্সেসের জন্য অনুমোদিত না হন তবে সার্ভারের পক্ষ থেকে আপনি এই ডেটা সুরক্ষিত রেখেছেন তারা এটিকে গ্রহণ করবে না , এবং আপনার কৌনিক অ্যাপ্লিকেশনটি 401 যথাযথভাবে পরিচালনা করতে হবে।

আপনি যদি কাঁচা ডেটা সুরক্ষিত করার চেষ্টা করছেন তবে আপনি ক্লায়েন্টের পক্ষে থাকতে পারবেন না, যদি আপনি কেবলমাত্র কোনও নির্দিষ্ট ব্যবহারকারীকে সাধারণভাবে নির্দিষ্ট উপায়ে নির্দিষ্ট উপায়ে দেখতে সক্ষম হতে চান তবে সার্ভারে প্রেরণের পরিবর্তে ডেটা 'ভিউ' তৈরি করতে পারেন ক্লায়েন্টের কাছে কাঁচা ডেটা এবং এটির পুনর্গঠন করা (আপনার আগে থেকেই পারফরম্যান্সের কারণে এটি করা উচিত)।

পার্শ্ব দ্রষ্টব্য: কৌনিক অনুরোধ টেমপ্লেটগুলির মধ্যে কখনও সংবেদনশীল কিছু থাকা উচিত নয়, কেবল এটি করবেন না। যদি কোনও ক্রেজি কারণে হয়, আপনার সার্ভার সাইডে এই ভিউ টেমপ্লেটগুলি রক্ষা করা দরকার, ঠিক যেমন আপনি যদি সার্ভার সাইড রেন্ডারিং করছিলেন।