Рубрики

Достаточно ли безопасно ваше веб-приложение? Подумай еще раз

Реальный мир работает на топливе, а Виртуальный мир — на безопасности.

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

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

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

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

Десять основных угроз против веб-приложений:

        1. Инъекция: когда пользователь вводит данные в формы через поля ввода, они сохраняются и отображаются с использованием базы данных (SQL, LDAP). Они часто встречаются в запросах SQL, LDAP, Xpath или NoSQL; Команды ОС; Синтаксические анализаторы XML, заголовки SMTP, программные аргументы и т. Д. Команды оболочки, внедряемые такими методами, могут дать злоумышленнику доступ к операционной системе и другим связанным внешним программам для выполнения любой вредоносной задачи. Другими словами, SQL-инъекция позволяет злоумышленникам передавать вредоносный код через веб-приложение в другие системы. Это может обмануть приложение при выполнении и выполнении процесса, который не был указан для запуска действительным пользователем / администратором. Это может привести к потере или повреждению данных, отсутствию ответственности или отказу в доступе. Инъекция иногда может привести к полному захвату хоста.
        1. Сломанная аутентификация и управление сеансами. Сломанная аутентификация и управление сеансами позволяет злоумышленникам получать такие данные, как пароль, токены и идентификаторы сеансов, которые затем позволяют им входить в учетную запись этого пользователя и выдавать себя за них для выполнения транзакций. Учетные записи могут быть взломаны злоумышленниками с помощью идентификаторов активных сеансов, указанных в URL-адресах. Чтобы избежать таких атак, учетные данные пользователя должны передаваться через зашифрованные соединения и храниться с использованием концепций хеширования и шифрования. Таймаут идентификаторов сеансов и аутентификация должны быть выполнены, чтобы предотвратить такие угрозы. Повторная аутентификация в случае забытого пароля должна быть сделана, чтобы проверить личность пользователя.
  1. Межсайтовый скриптинг (XSS) : это происходит, когда пользователь вводит данные без проверки введенного пользователя. и эти ненадежные данные отправляются в приложение без проведения надлежащей проверки (сценарии на стороне браузера) . В следующий раз, когда другой пользователь посещает сайт или запускает то же приложение, он становится свидетелем того, как приложение ведет себя так, как злоумышленник хотел, чтобы оно работало. Вредоносный скрипт может получить доступ к файлам cookie, токенам сеанса или любой другой конфиденциальной информации, хранящейся в браузере и используемой на этом сайте. Эти сценарии также могут переписать содержимое HTML-страницы.
  1. Небезопасная прямая ссылка на объект : это происходит, когда ссылка (объект, файл или база данных) открывается для просмотра / изменения / использования пользователем, который не проверен для доступа (авторизация). Эти недостатки позволяют злоумышленникам скомпрометировать все данные, связанные с измененным параметром. Как только злоумышленник найдет способ проникнуть в приложение, он, скорее всего, найдет способ копать глубже и скомпрометировать любые возможные данные. Пример: доступ предоставляется всем пользователям, когда только администратор должен иметь право доступа для просмотра / использования / изменения данных.
  1. Неправильная настройка безопасности : приложение, сервер приложений, веб-сервер, сервер базы данных должны иметь безопасные конфигурации . Разработчики и системные администраторы должны работать вместе, чтобы убедиться, что весь стек настроен правильно. Если система скомпрометирована из-за неправильной конфигурации безопасности, данные могут быть украдены или изменены медленно с течением времени.
  1. Чувствительный воздействие данных: S ensitive данные как данные кредитной карты не могут быть защищены наилучшим образом. Злоумышленники могут взломать такие базы данных и проводить транзакции с использованием этих данных. Это включает в себя данные и резервное копирование этих данных. Злоумышленники не могут напрямую взломать шифрование, они крадут ключи, вызывают атаки посредников или крадут чистые текстовые данные с сервера или браузера. Единственный способ защитить такие конфиденциальные данные — использовать надежные алгоритмы шифрования.
  1. Отсутствует контроль доступа на уровне функций : авторизация на уровне функций должна присутствовать как на приложении, так и на серверах. Большинство веб-приложений проверяют права доступа на уровне функций, прежде чем сделать эту функцию доступной для пользователя. Однако, если проверки контроля доступа не выполняются на сервере, хакеры смогут проникнуть в приложение без надлежащей авторизации. Запросы необходимо проверять с обеих сторон, чтобы препятствовать подделке запросов на доступ к функциональности без действительной авторизации . Пример : анонимные пользователи получают доступ к частным функциям или обычные пользователи могут использовать привилегированные функции, если контроль доступа на уровне функций не реализован.
  1. Подделка межсайтовых запросов (CSRF) : также известна как атака одним щелчком мыши или перехват сеанса. Этот недостаток позволяет злоумышленнику заставить конечного пользователя выполнять нежелательные действия в веб-приложении, в котором они в настоящий момент проходят проверку подлинности, и отправлять поддельный HTTP-запрос вместе с данными проверки подлинности пользователя на уязвимый веб-сайт. Это фактически приводит к нежелательной функции от имени жертвы. Пример : большинство подозрительных ссылок вы получаете через подозрительные или неопознанные источники по почте.

  1. Использование компонентов с известными уязвимостями . Некоторые инструменты, используемые для разработки приложения, могут иметь недостатки в безопасности, которые уже являются известным фактом и известны злоумышленникам . Внедрение такого инструмента нецелесообразно, так как это может привести к возникновению большинства недостатков, упомянутых выше. Злоумышленник знает слабость одного компонента, поэтому он может знать, какие другие конкретные области приложения уязвимы из-за этого недостатка. Практически у каждого приложения есть эти проблемы, потому что большинство групп разработчиков не сосредоточены на том, чтобы обеспечить соответствие своих компонентов / библиотек Дата. Во многих случаях разработчики даже не знают всех компонентов, которые они используют, не говоря уже о их версиях. Зависимости компонентов делают вещи еще хуже.
  1. Недействительные перенаправления и пересылки : веб-приложения могут перенаправлять или перенаправлять пользователей на другие веб-сайты. Злоумышленники могут пересылать пользователей на неавторизованные страницы или перенаправлять их на вредоносные сайты или обманывать пользователей, чтобы они раскрыли конфиденциальную информацию, такую как пароли. Поскольку вредоносная ссылка модифицируется так, чтобы выглядеть идентично исходному сайту, попытки фишинга могут иметь более надежный вид.

Хотя все вышеперечисленные факты очень хорошо объяснены в ссылках ниже; Мое намерение состоит в том, чтобы просто взглянуть на все угрозы безопасности, о которых мы должны знать как пользователи Интернета.

Ссылки

Жадный читатель и музыкальный маньяк, Варша учится на последнем курсе бакалавриата ACED, Бангалор Помимо того, что она является технологическим энтузиастом, она — активный блоггер, пишущий на темы, начиная от социальных вопросов, жизненного опыта, затянувшихся мыслей и вымысла. Вы можете связаться с ней через твиттер @ varsh2v3

Если вы также хотите продемонстрировать свой блог здесь, пожалуйста, смотрите GBlog для записи гостевого блога на GeeksforGeeks.

Рекомендуемые посты:

Достаточно ли безопасно ваше веб-приложение? Подумай еще раз

0.00 (0%) 0 votes