Взламывание веб-сайта - Почему всегда возможно сделать?

Дело в том, что хакеры всегда на шаг впереди разработчиков, вы никогда не сможете считать сайт пуленепробиваемым и на 100% безопасным. . Просто избегайте вредоносных вещей, насколько можете! На самом деле, когда дело касается безопасности, вам следует придерживаться подхода с использованием белого списка, а не черного списка.

Возможно, это не тот сайт, чтобы обсуждать это. Однако широко известно, что безопасность и удобство использования обратно пропорциональны. См., Например, этот пост Брюса Шнайера (который относится к другому веб-сайту, но в блоге Шнайера есть много интересных материалов по этому поводу).

Могу я взломать ваш сайт? Конечно, я просто найму несколько террористов-смертников, чтобы взорвать ваши серверы. Или ... Я взорву те электростанции, которые питают ваш сайт, или я проведу какую-то социальную инженерию, и DDOS-атаки, скорее всего, будут эффективны в больших масштабах, не говоря уже об атомных бомбах ...

Краткий ответ: да.

Предполагая сам сервер не компрометирован и не имеет других клиентов, разделяющих его, статический код должен быть в порядке. Обычно все становится напуганным только тогда, когда задействован какой-то язык сценариев. В конце концов, я никогда не видел компрометирующего "Это работает!" страница

Невозможно сделать что-либо на 100% безопасным.

Все, что можно сделать, - это сделать что-то достаточно сложное, чтобы взломать его, чтобы время и усилия, потраченные на это, не стоили того.

Не придираться, но ваше определение «хорошего хостинга» не предполагает, что служба HTTP, работающая на хосте, полностью свободна от эксплойтов.

Популярные веб-серверы, такие как IIS и Apache, являются часто исправляются для защиты от таких эксплойтов, которые часто обнаруживаются таким же образом, как и эксплойты в локальных исполняемых файлах.

Например, неверно сформированный HTTP-запрос может вызвать переполнение буфера на сервере, что приведет к тому, что часть его данных окажется казнен.

Веб-сайты сильно страдают от атак инъекций и межсайтовых сценариев атак

Межсайтовых сценариев, выполняемых на веб-сайты составляли примерно 80% всех задокументированные уязвимости безопасности как of 2007

Также часть веб-сайта (на некоторых веб-сайтах очень много) отправляется клиенту в форме CSS, HTML и javascript, которые открыты для проверки любым.

Подытожим и добавим к предшествующим сообщениям:

1. Интернет как общий ресурс - веб-сайты полезны пока они доступны. Сделайте веб-сайт недоступным, и вы его сломали. Атаки отказа в обслуживании приводят к переполнению сервера, так что он больше не может отвечать на легитимные запросы, всегда будет важным фактором. Это игра «держись подальше» - большие серверные сайты находят способы распространения, хакеры находят способы наводнять поток.
2. Динамические данные = динамический риск - если пользователь может вводить данные, у хакера есть шанс стать помощником . Сегодня главными концепциями являются межсайтовые сценарии и SQL-инъекции, но как только будет определен один способ взлома, высоки шансы, что появится другой механизм. Вы могли бы, возможно, утверждать, что полностью статический сайт может быть защищен от этого, но тогда сколько полезных сайтов соответствует этому счету?
3. Сложность = чем сложнее, тем труднее защитить - учитывая быстрое изменение технологий, я сомневаюсь, что любой веб-разработчик мог со 100% уверенностью сказать, что современный веб-сайт безопасен - слишком много неизвестного кода. Если не брать в расчет хост (сервер, сетевые протоколы, ОС и, возможно, базу данных), в Java EE и .Net все еще есть все замечательные новые библиотеки. И даже менее корпоративная архитектура будет иметь серьезную сложность, из-за которой знание всех потенциальных входов и выходов кода будет непомерно трудным.
4. Проблема аутентификации = по определению, веб-сайт позволяет удаленному пользователю делать что-то полезное. на сервере, который находится далеко. Знать другой конец коммуникации и доверять ему - давняя проблема. В наши дни аутентификация на стороне сервера относительно хорошо реализована, и (насколько я знаю!) Никому не удалось взломать PKI. Но сгладить аутентификацию пользователя по-прежнему довольно сложно. Это выполнимо, но это компромисс между сложностью для пользователя и конфигурации и системой с более высоким риском уязвимости. И даже сильная система может сломаться, если пользователи не соблюдают правила или когда случаются аварии. Все это неприменимо, если вы хотите сделать сайт общедоступным для всех пользователей, но это сильно ограничивает возможности, которые вы сможете реализовать.

Я бы сказал, что веб-сайты просто меняют характер проблемы безопасности. от проблем кода на стороне клиента. Разработчику не нужно беспокоиться о репликации кода, но разработчик должен осознавать риски, связанные с централизацией данных и доступом к серверу (или набору серверов). Это просто проблема другого рода.

Главное помнить, что веб-сайты обычно являются частью огромной и сложной системы, и на самом деле не имеет значения, входит ли хакер в систему через само веб-приложение или какую-либо другую часть вся инфраструктура. Если кто-то может получить доступ к вашим серверам, маршрутизаторам, DNS или чему-то еще, он может вывести из строя даже лучшее веб-приложение. По моему опыту, многие системы так или иначе уязвимы. Таким образом, «полностью защищенный» означает либо «мы очень стараемся защитить платформу», либо «мы не имеем ни малейшего понятия, но надеемся, что все в порядке». Я видел оба.

Да, это всегда возможно. Всегда есть выход.

Как всегда говорил мой дед:

Замки предназначены для того, чтобы держать честных люди из

Вы можете легко написать веб-приложение, безопасность которого математически доказана ... Но это доказательство будет действовать только до тех пор, пока базовая операционная система, интерпретатор | компилятор и оборудование защищены, чего никогда никогда не бывает.

Да, возможно , чтобы веб-сайт был полностью безопасным, при разумном определении термина «полный», включающем исходную предпосылку о том, что хостинг не уязвим. Проблема такая же, как и с любым программным обеспечением, содержащим дефекты; люди создают программное обеспечение со сложностью, которая немного выходит за рамки их возможностей управлять, и поэтому недостатки остаются незамеченными, пока не станет слишком поздно.

Вы можете начать с малого и доказать, что вся ваша работа правильная и безопасная, когда вы ее создаете, переделывая любые нестандартные решения. полочные компоненты, которые не были разработаны с учетом такого строгого уровня качества, но, к сожалению, это ставит вас в невыгодное коммерческое положение по сравнению с людьми, которые могут написать 99% безопасное программное обеспечение в 1% случаев. Поэтому там '

Можно ли сказать, что веб-сайт может быть полностью защищен от атак хакеров ( мы предполагаем, что хостинг не уязвим )?

Хорошо, если мы собираемся начать накладывая ограничения на злоумышленника, тогда, конечно, мы можем разработать полностью безопасную систему: нам просто нужно исключить из сценария все атаки злоумышленника.

Если мы предположим, что злоумышленник действительно хочет проникнуть внутрь (и не связан по правилам вашего взаимодействия), то ответ будет просто отрицательным, вы не можете полностью обезопасить себя от атак.

Суть в том, что большую часть времени вы должны найти баланс между простотой использования и безопасностью и решить, что обеспечивает оптимальный уровень обоих для ваши цели.

Прекрасный тому пример - пароли. Самый простой способ сделать это - просто иметь один, использовать его везде и сделать что-то легко запоминающееся. Безопасный способ сделать это - иметь случайно сгенерированную последовательность символов переменной длины по всему спектру кодирования, который знает только сам пользователь.

Естественно, если вы зайдете слишком далеко в легкой части, пользовательские данные будут легкими забрать. Однако, если вы зайдете слишком далеко в сторону безопасности, практическое применение может привести к ситуациям, которые ставят под угрозу добавленную стоимость мер безопасности (например, люди могут • запомнить всю связку паролей и соответствующих имён пользователей, и поэтому записать их где-нибудь. Если список скомпрометирован, принятые меры безопасности окажутся напрасными. Следовательно, в большинстве случаев баланс достигается, и места просят вас указать число в своем пароле и говорить вам не делать ничего глупого, например, сообщать это другим людям.

Даже если вы устраните возможность злонамеренного человека с помощью ключи ко всему, утечка данных из уравнения, человеческая глупость безгранична. 100% безопасности не существует.

Даже если вы исключите возможность злонамеренного человека с ключами ко всему утечке данных из уравнения человеческая глупость безгранична. 100% безопасности не существует.

Даже если вы исключите возможность злонамеренного человека с ключами ко всему утечке данных из уравнения человеческая глупость безгранична. 100% безопасности не существует.

Прикрепите следующий фрагмент кода к событию TextBox.KeyDown , чтобы найти точку на экране курсора в элементе управления текстовым полем:

using (Graphics g = Graphics.FromHwnd(textBox1.Handle))
{
    SizeF size = g.MeasureString(textBox1.Text.Substring(0, textBox1.SelectionStart), textBox1.Font);

Point pt = textBox1.PointToScreen(new Point((int)size.Width, (int)0));
    label1.Text = "Manual: " + pt.ToString();
}

Приведенный выше фрагмент кода учитывает учитывать шрифт, используемый элементом управления TextBox , чтобы правильно вычислить фактическую длину строки до позиции курсора в элементе управления. При выполнении всплывающего окна автозавершения в стиле «Intellisense» важно знать фактическое положение экрана, чтобы отобразился список «Автозавершение».

Это то, что делает фрагмент. Он вычисляет ширину текста, затем преобразует его в «локальную» координату элемента управления TextBox и оттуда преобразует эту точку в соответствующую экранную координату.

Одно предостережение, которое следует учитывать: SelectionStart задерживается и не обновляется немедленно. Частично это связано с тем, как элемент управления текстовым полем обрабатывает ввод с клавиатуры.