GWT RPC server side safe deserialization to check field size

Question

Suppose I send objects of the following type from GWT client to server through RPC. The objects get stored to a database.

public class MyData2Server implements Serializable
{
    private String myDataStr;
    public String getMyDataStr() { return myDataStr; }
    public void setMyDataStr(String newVal) { myDataStr = newVal; }
}

On the client side, I constrain the field myDataStr to be say 20 character max.

I have been reading on web-application security. If I learned something it is client data should not be trusted. Server should then check the data. So I feel like I ought to check on the server that my field is indeed not longer than 20 characters otherwise I would abort the request since I know it must be an attack attempt (assuming no bug on the client side of course).

So my questions are:

1. How important is it to actually check on the server side my field is not longer than 20 characters? I mean what are the chances/risks of an attack and how bad could the consequences be? From what I have read, it looks like it could go as far as bringing the server down through overflow and denial of service, but not being a security expert, I could be mis-interpreting.

2. Assuming I would not be wasting my time doing the field-size check on the server, how should one accomplish it? I seem to recall reading (sorry I no longer have the reference) that a naive check like

   if (myData2ServerObject.getMyDataStr().length() > 20) throw new MyException();

is not the right way. Instead one would need to define (or override?) the method readObject(), something like in here. If so, again how should one do it within the context of an RPC call?

Thank you in advance.

Answer 1

How important is it to actually check on the server side my field is not longer than 20 characters?

It's 100% important, except maybe if you can trust the end-user 100% (e. g. some internal apps).

I mean what are the chances

Generally: Increasing. The exact proability can only be answered for your concrete scenario individually (i. e. no one here will be able to tell you, though I would also be interested in general statistics). What I can say is, that tampering is trivially easy. It can be done in the JavaScript code (e. g. using Chrome's built-in dev tools debugger) or by editing the clearly visible HTTP request data.

/risks of an attack and how bad could the consequences be?

The risks can vary. The most direct risk can be evaluated by thinking: "What could you store and do, if you can set any field of any GWT-serializable object to any value?" This is not only about exceeding the size, but maybe tampering with the user ID etc.

From what I have read, it looks like it could go as far as bringing the server down through overflow and denial of service, but not being a security expert, I could be mis-interpreting.

This is yet another level to deal with, and cannot be addressed with server side validation within the GWT RPC method implementation.

Instead one would need to define (or override?) the method readObject(), something like in here.

I don't think that's a good approach. It tries to accomplish two things, but can do neither of them very well. There are two kinds of checks on the server side that must be done:

1. On a low level, when the bytes come in (before they are converted by RemoteServiceServlet to a Java Object). This needs to be dealt with on every server, not only with GWT, and would need to be answered in a separate question (the answer could simply be a server setting for the maximum request size).
2. On a logical level, after you have the data in the Java Object. For this, I would recommend a validation/authorization layer. One of the awesome features of GWT is, that you can use JSR 303 validation both on the server and client side now. It doesn't cover every aspect (you would still have to test for user permissions), but it can cover your "@Size(max = 20)" use case.