DEV Community: Deepak

Editing the Java compiler

Deepak — Sat, 04 Mar 2023 06:03:27 +0000

Compilers always fascinated me throughout my career. I suppose it was the ability of the compiler to take a high level piece of code and quickly translate it into something that executes. I have tried writing a compiler from scratch once (for my own programming language) and it didn't go well but I was able to learn a lot from it. Fast forward to today, I finally edited the "openjdk17" / "corretto-17" java compiler to add my own grammar and functionality.

The "javac" command that you generally use to compile high level java code to a .class file or bytecode, is actually surprisingly written in java. This is known as a bootstrap compiler or a "self compiling compiler". It's a compiler written for a language in that language.

The Javac compiler has several stages at a detailed level but the main steps of compiling still adheres to the compiler theory / compiler design concepts. They are:

Lexical Analysis (Tokenizing)
Syntax Analysis (Parsing) (Generates a parse tree)
Semantic Analysis (Type checking, Dead code analysis, etc)
Intermediate Code Generation (optional)
Target Code Generation (Bytecode)
Code Optimization

After the parse tree is generated, every other stage is a visitor. It follows the visitor design pattern. There is a Flow visitor (checks Dead code), There is an Enter visitor (which collects Symbols like methods, classes). There is a Attr visitor which does Type checking. Etc.

To get started on editing the javac compiler, you need to first set up the openjdk codebase locally. Unfortunately, I couldn't find a good set of tools for compiler development but I found vscode to be the easiest in this case. IntelliJ also works but I prefer vscode here. This page describes how to setup the codebase locally.

The feature I am trying to add here, is the "Javascript's Option Chain" operator or the "?." operator. After navigating through the code, it appears that the grammar has to be written alongside the ternary operator's grammar code. This piece of code is present in the JavacParser.java file. Here's where all parsing to a JCTree happens.

 /** Expression1Rest = ["?" Expression ":" Expression1]
     */
    JCExpression term1Rest(JCExpression t) {
        if (token.kind == QUES) {
            int pos = token.pos;
            nextToken();
            // option chaining
            if (token.kind == DOT) {
                accept(DOT);
                var ident = ident();
                JCExpression returnable = F.at(pos).Conditional(
                        F.at(pos).Parens(F.at(pos).Binary(optag(TokenKind.EQEQ), F.at(pos).Literal(TypeTag.BOT, null), t)),
                        F.at(pos).Literal(TypeTag.BOT, null), F.at(pos).Select(t, ident));
                return term1Rest(returnable);
            }
            // ternary
            JCExpression t1 = term();
            accept(COLON);
            JCExpression t2 = term1();
            return F.at(pos).Conditional(t, t1, t2);
        } else {
            return t;
        }
    }

Here, the grammar is accepted by calling accept(DOT). DOT is a token defined in Tokens.java

The way this functionality works, is by replacing the JCFieldAccess Select(...) subtree with a custom tree similar to this code:

(t == null) ? null : t.ident;

This is how option chaining works.

An example of how this feature works is like so:

Code snippet:

public class Test {
        public static void main(String[] args) {
                Car car = new Car();
                Integer wheel1 = car?.w1?.x;
                Integer wheel2 = car?.w2?.x;
                System.out.println("value of wheel1 is: " + wheel1);
                System.out.println("value of wheel2 is: " + wheel2);
        }

        public static class Car {
                Wheel w1 = null;
                Wheel w2 = new Wheel();
                public Car() {
                }
        }

        public static class Wheel {
                int x = 2;
                public Wheel() {
                }
        }
}

This still isn't perfect and has its own problems but regardless it was a quite interesting journey of understanding how the compiler is written. I was able to learn a lot of things from this.

References:

https://openjdk.org/groups/compiler/doc/hhgtjavac/index.html

My commit:

https://github.com/corretto/corretto-17/commit/37b125992c7d2b6fb55216e553168bf7b8a3a4b4

Less boring way to build an MVP

Deepak — Sat, 04 Jun 2022 05:53:14 +0000

Whenever you want to build a product, you never start out with building the entire product. Often times your first goal is to build a Minimum Viable Product (MVP). This is done so that you can test the Product Market Fit before you even build the entire complex project.

However, building an MVP isn't fun if you're uncertain that it will give any good results at all. In fact, it's very draining. I thrive on certain good results and uncertainty doesn't help it.

The first step to enhance the experience of building an MVP is by building the end goal right away. It sounds weird but it totally works.

Let's suppose that we're trying to build a social media website where people can post memes in their pages, and others add comments and stuff. The traditional way to go about this is like this:

Build the login UI (Nothing fun yet)

Setup the database

Build the login backend

Setup the tables for pages

Setup the tables for posts

Build the UI for the posts and images (Still can't use it because it's tied to the backend and the backend isn't implemented yet)

And so on and so forth...

Most people would feel like quiting at step 3. This is because we haven't reached our end goal yet and we're uncertain if it works and we don't even know how the end product would look like. Let's try a slightly better approach. Our main goal here is to let people create pages, post memes and add comments on them. Let's do that first.

Build the end goal UI functionality. (Allow people to upload things and view whatever is uploaded (don't save it. You don't have to). Mock any APIs that you may need.

Build other less fun UI components like login page, etc.

Slowly build the backend component by component for all of this and make them better.

I find this to be a much better way to go about prototyping products. At step 1, you already have what you're looking for which is going to inspire you. You can play around with what's going to be the future MVP which is going to be fully functional. At step 2, it is less boring considering you already have your end goal. All you're doing is just adding more UI components to your end goal. At step 3, it would feel like you're adding upgrades or patches to things that are already present.

Even though this doesn't solve the entire uncertainty problem, it is still much better than the traditional approach to go about prototyping products. Let me know if you have tried this and I will look forward to finding better ways of building an MVP.

Confused Deputy Attack in OAuth 2.0

Deepak — Wed, 11 May 2022 20:33:09 +0000

If you were to build an app or a website today for the general public, it's very likely that you'll be implementing an OAuth based login system. If you don't know what OAuth is (It is summarised in this blog), I recommend you to read the original RFC of OAuth 2.0 (RFC 6749). In short, OAuth login systems look like this:

When the user clicks on Login with X or anything similar, this is what happens in the background (According to RFC 6749 but with one tweak being "server calls the user_details API", for our example here.):

As you can see, the only thing that's being checked by the OAuth provider is the token. There are no extra fields that's being used to check things. Let's say that the scope for which the client is registered, is "profile_info" and returns us the email ID of the user.

This is where the confused deputy attack comes into the picture.

Suppose you registered a new client with the name "Normal Client", client_id 1 and client_secret 123, and another client with the name "Attacker Client", client_id 2 and client_secret 456. Let's say that for some reason, alice@x.com logged into Normal Client which generated a token for the Normal Client, and received access to delete something. Let's also say that for some reason, alice@x.com logged into Attacker Client generating a token for the Attacker Client. Let's say that the Normal Client's server is the Normal Server and that the Attacker Client's server is the Attacker Server.

Since there are no additional checks on the token, the Attacker Server could use this token generated for the Attacker Client, which is not identical to the Normal Client's token, to gain access as alice@x.com to Normal Server. This will allow the Attacker Server to gain access they weren't given.

Solution:

Anything that can add additional validation to the token either at the OAuth provider's side or the server's side will make things a lot more secure and prevent Confused Deputy Attacks. Examples of this are:

Generating JWT tokens instead of normal tokens and embed information like client_id within the token. Since nobody can alter the state of the JWT token, the client_id will not be tampered with. This client_id can be checked at the server's end or at the OAuth Provider's end.
Using a flag based scope. Even though scopes are meant to describe the level of information that is given to the authorising server (profile_info, profile_picture, contacts), the RFC doesn't really restrict the usage of scope to this. Therefore scopes can be used to restrict access. Although, this becomes a problem if the OAuth provider is widely used.
Sending client_id in the user_details API or the API that validates the token. This doesn't follow the OAuth RFC but it still can be done.

References:

https://en.wikipedia.org/wiki/Confused_deputy_problem

https://security.stackexchange.com/questions/66077/oauth-implicit-flow-and-confused-deputy-problem

https://datatracker.ietf.org/doc/html/rfc6749