We are created textField which is
and we are using the onNameTypedValueChange event once we enter the data in the textField every time request is call and data is shown in the plain text. This data should not be visible in the request for that we want to perfom client side encryption how can we do this.
Use HTTPS. Anything else is just giving a false sense of security since you anyways have to protect against a man in the middle stealing the encryption keys.
In in case you already have HTTPS enabled, which is almost always the case, adding this kind of encryption will not give you any additional value, as the the whole communication channel is already encrypted.
Yeah. And if you don’t have HTTPS enabled, then no amount of custom client-side encryption will help you since an attacker can just as well rewrite the plain-text response that delivers the JavaScript for doing encryption to replace it with an implementation that doesn’t do any encryption.
We are retrieving the data and showing this data in the text filed but on that text filed the change event is call like this
@Subscribe(“name”)
public void onNameTypedValueChange(final SupportsTypedValue.TypedValueChangeEvent<TypedTextField<?>, ?> event) {
nameVal.setValue(name.getValue());
}
earlier I told each value change the new request is generated and data is shown in the request as per the application security team the plain text data are visible is vulnerable according to them.
I guess the user should be able to see the value? For that to be true, it needs to be possible to decrypt it, which means that the decryption key would also have to be sent. Which means that anyone who can read what’s sent over the network will anyways have all they need to also read the value.
You either forgot to apply proper security within your network - by not enabling HTTPS or your security team is already abusing MITM. Don’t change the framework, change your environment.
It seems you don’t want to understand us. That’s a false sense of security.
If you are legally required to “double” encrypt your data before it hits the wire you need to overwrite the client side of Vaadin’s components and manipulate the value on each change event before it gets passed to the server. You might be able to get an understanding of how by checking the text formatter plugin in the directory.
You have a bug there and it’s clearly visible in the screenshot. The bug is that the protocol is http:// rather than https://. If you fix that bug, then Burp Suite will not see anything from the request (unless you configure it to cheat but that that could also be done for any other encryption that you add).
It’s visible in plain text only for those who know the private key. When you’re using Burp Suite, you typically configure your browser or OS to trust Burp’s certificate which gives it the power to decrypt requests and responses. Regular users on the internet don’t have that kind of power.
I’m not sure what you wanna tell us here? That’s exactly how tampering on the network level is suppose to work. What do you expect from Vaadin here? Secure your environment properly.
I am saying while clicking on submit button or submitting form to server data is not visible in plain text. It is visible only when we used change events for any textFiled or comboBox.
All data exchanged between the browser and the server is visible on the network in some form. However, when SSL/TLS is used, the browser and the server agree on an encryption method and establish a secure connection. This encryption process is handled at a lower level and is independent of Vaadin or any specific web application framework.
If you’re still able to see plain text data even with SSL enabled, it usually means that the tool you’re using has access to the encryption keys. This typically happens when there’s a proxy or an intercepting tool (like a corporate firewall or security scanner) sitting between the browser and the server, decrypting and re-encrypting the traffic for inspection.
If you need to demonstrate to auditors that the data between the browser and your server is encrypted, you can use a network analysis tool like tshark to capture the traffic. Share the capture with them so they can verify that the contents are indeed encrypted and not readable in plain text.