Как я могу защитить (зашифровать с помощью кода Java) значения формы входа, которые будут перенаправлены на сервлет - PullRequest
0 голосов
/ 05 июня 2018

У меня проблема безопасности при отправке защищенных данных (зашифрованных перед отправкой запроса) сервлету.Я попытался вызвать функцию, которая делает шифрование для пароля в качестве примера, но я не могу передать значение из сценария Java в код Java в JSP.

<script>
	function login() {
		var password = document.getElementsByName("newPassword");
		console.log(password);
	}
</script>
</head>
<body>
	<form class="login" action="servlet example" method="Post">
		<h1 class="login-title">BSH Login</h1>
		<h3><%=request.getAttribute("message") != null ? request.getAttribute("message") : ""%></h3>
		<input type="text" class="login-input" name="username"
			placeholder="Bsh UserName" autofocus> <input type="password"
			name="passowrd" class="login-input" placeholder="Password"> <input
			type="submit" value="Login" onclick="login()" class="login-button">
	</form>

</body>

Мне серьезно нужно отправить зашифрованные данные из JSP в сервлет без HTTPS.

Ответы [ 3 ]

0 голосов
/ 05 июня 2018

Ваш вопрос не очень понятен.

Если вы хотите отправить какие-либо учетные данные (или вообще что-либо) с клиента на сервер, единственным вариантом будет https.

Но если вы оПередавая некоторые данные из jsp сервлету, внутренний диспетчер запросов локально защищен и не имеет отношения к клиенту.но если вы перенаправляете между шлюзами, потому что вам нужны клиентские перенаправления вызовов, вам все равно нужен https.

0 голосов
/ 05 июня 2018

Правильное (и, возможно, единственное) решение - использовать HTTPS.Это установит безопасное соединение с сервером для отправки запроса на вход.Поскольку все данные, передаваемые по HTTPS-соединению, зашифрованы, дополнительное шифрование пароля не потребуется.


Предположим, что вы хотите использовать незащищенное соединение (т. Е. HTTP вместо HTTPS).Можно ли использовать шифрование для отправки пароля ... надежно?

Я думаю, что ответ - нет.

В этом сценарии пусть Алиса будет пользователем, Боб будет сервероми Кэрол будет человеком / агентом, пытающимся перехватить пароль.

Предположим, что Алиса отправляет HTTP-запрос для получения страницы входа, а Боб отвечает страницей с некоторым встроенным Javascript, который зашифрует пароль пользователя.Javascript Боба может даже использовать шифрование с открытым ключом, чтобы Кэрол 1 могла расшифровать пароль ... несмотря на знание ключа шифрования.(Можно подумать ...)

К сожалению, это НЕ безопасно.Проблема в том, что Боб отправил страницу, содержащую ваш javascript, в веб-браузер Алисы в открытом виде.Кэрол может использовать известные методы взлома сети, чтобы изменить ответ Боба, чтобы на странице, которую получает Алиса, была другая версия javascript.Эта версия может отправлять пароль в открытом виде или шифровать его другим открытым ключом.Это приведет к тому, что Алиса не сможет войти в систему.Но если Кэрол также может увидеть запрос на вход в систему (потому что он также был отправлен по HTTP), то она может получить пароль Алисы.Действительно, Кэрол может заставить запрос отправляться через HTTP.

Это пример атаки безопасности "человек посередине" (MITM).

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

0 голосов
/ 05 июня 2018

При использовании веб-запроса как такового.Я бы предложил использовать веб-токены JSON, которые можно найти здесь: https://jwt.io.

Эта программа / инструмент позволит вам встраивать зашифрованные данные и проверять данные после отправки и получения (особенно получения).Не стесняйтесь читать документацию и реализовывать ее в вашей среде Javascript или Java.

...