Я знаю, що це досить суперечливий погляд, я повинен пояснити деякі з моїх власних фонових знань щодо того, що мені це не подобається. У погані часи я був тестувальником проникнення; я провів свою власну маленьку компанію, яка надала цю послугу багатьом клієнтам, моє завдання полягало в тому, щоб, по суті, зламати / іншими способами веб- сайти та " інші " мережі. За мого часу як тестувальника пера, однією з найбільш надокучливих речей було недоліки, які могли б призвести до величезної кількості сайтів / інсталяцій одночасно, класики були вадами паролів Cisco, Perl і PHP- помилок, і, що найгірше, у інтернет- програмах. Отже, з плином часу і я перемістив більше в написання застосувань замість того, щоб їх порушувати, я завжди усвідомлював, що системи безпеки програм не повинні повністю довіряти, в той же час менша ймовірність того, що вони матимуть недоліки, ніж деякі рекламні реалізації, цей недолік може бути потенційно серйознішим, оскільки є майже певним, що вони стануть широко відомими і експлуатуються протягом дуже короткого часу. Це частина проблеми, яку я маю з RequestRequest, вона забезпечує мийку, скорочення для лінивого розробника. Гаразд, вона корисна, вона блокує будь- які вхідні дані " html ," на зразок запиту, - отже блокує багато нападів XSS (Cross Site scripting), які можуть бути досить серйозними. Проблема полягає у тому, що Недоліки вже знайдено в цьому і латка не є очевидною / простою для пошуку (чи ви вже чули про неї?) - отже, немає проблем, які б посприяли тому, що ВСІ АСП. NET 1. 1 сайти, які покладаються на цю можливість, захистять їх від нападів XSS. Навіть гірше того, скільки сайтів, на вашу думку, потребують додаткових запобіжних заходів, щоб захистити свої вхідні дані. Чи знаєте ви, чи захистять вони вас від нападів XSS? Напади ін'єкції SQL, Напади переповнення буфера і багато інших (включаючи такі самоцвіти, як прості задні двері, Викрадення з куками і тому подібне).

Я вважаю, що відповідальність за забезпечення безпеки за життя повинна лежати з розробником - вони повинні розуміти і планувати наслідки вибору, який вони роблять у застосовуванні проекту. Прочитайте книжку на зразок цього. Напис Майкла Говарда " Безпечний код " [СШАПознайомся з тим, де можуть збрехати ваші вразливості і компенсувати їх. Коротко кажучи, не покладайтеся на такі речі, як ChestRequest як ваш єдиний рядок захисту - використовуйте їх усіма способами, це зупинить багато речей, через які ви можете не хотіти - але навчіться що він насправді робить і що ні.

Наприклад, що ви будете робити, коли хочете, щоб деякі мітки проходили через них, а не інші? щось на зразок цього(Я написав це кілька років тому - я не стверджую, що це повністю чи навіть частково необґрунтовано - це просто доказ концепції).

Як би там не було, перегляди завжди вітають - скільки безпеки застосувань ви повинні доручити програмі - чи хтось інший придумав свої власні маленькі іграшки "безпеки," які вони використовують для перевірки вхідної інформації користувача?

Не забудьте згадати, якщо ви досі на IIS 5.0, обов'язково перевіряйте. IISLockdown - ви повинні встановити це, воно допоможе вам уникнути величезної кількості отворів безпеки, відомої / майбутнього ... якщо у вас є IIS 6,0, він вже там, але будьте впевнені, що перевірити це щоб уникнути будь- яких проблем з розвитком...