Archive

Posts Tagged ‘hack’
  • Bypassing Javascript checks

    Police riot control training

    Nowadays, when a webapp offers a registration page, it usually duplicates the password field (or sometimes even the email field).

    By having you type the password twice, it wants to ensure that you didn’t make any mistake. And that you don’t have to reset the password the next time you try to login. It makes sense if you actually type the password. Me, I’m using a password manager. That means, I do a copy-paste the password I got from the password manager twice. So far, so good.

    Now, some webapps assume people do type the password. Or worse, people behind those apps don’t know about password managers. They enforce typing the password in the second password field by preventing the paste command in the field. That means that password manager users like me have to type more than 20 random characters by hand. It’s not acceptable!

    Fortunately, there’s a neat solution if you are willing to do some hacking. With any modern navigator, locate the guilty password input field and:

    • Get its id, e.g. myId
    • Get the name of the function associated with its onpaste attribute, e.g. dontPaste Event listeners in Google Chrome
    • Run the following in the JavaScript console:
    document.getElementById('myId').removeElementListener('paste', 'dontPaste');
    

    In some cases, however, the function is anonymous, and the previous code cannot be executed. Fine. Then, run:

    document.getElementById('myId').onpaste = null;
    

    Conclusions

    There are some conclusions to this rather short post.

    The first one, is that it’s really cool to be a developer, because it allows you to avoid a lot of hassle.

    The second one is to never ever implement this kind of checks. If the user doesn’t remember his password, then provide a way to reset it. You’ll need this feature anyway. But duplicating passwords makes it harder to use password managers. Hence, it decreases security. In this day and age, that’s not only a waste of time, it’s a serious mistake.

    Finally, it’s your “moral” duty as a developer to push back against such stupid requirements.

    PS: The complete title of this post should have been, “Bypassing stupid Javascript check”, but it would not have been great in Google search results…

    Categories: Development Tags: javascripthack
  • getCaller() hack

    Disclaimer: the following is a devious hack, it should only be used if you know what you’re doing.

    As developers, we should only call public APIs. However, the Java language cannot differentiate between public API and private stuff: as soon as a class and one of its method is public, we can reference the former and call the later. Therefore, we are exposed to the Dark Side of the Force, and sometimes tempted to use it.

    A good example of this terrible temptation is the sun.reflect.Reflection.getCaller(int) method. As its name implies, this evil piece returns which class called your current code, letting you tailor your code behavior depending on the calling class. The Dark Side can be seductive indeed!

    This way, we can check whether some caller has some property and let it invoke our stuff or not accordingly. For example, let’s design a code piece that can be invoked only from “privileged” code. Such privileges include: be a specific class, come from a specific package, be annotated with a specific annotation, etc. The following code uses the third option.

    import java.lang.annotation.Retention;
    import java.lang.annotation.Target;
    import static java.lang.annotation.ElementType.TYPE;
    import static java.lang.annotation.RetentionPolicy.RUNTIME;
    @Retention(RUNTIME)
    @Target(TYPE)
    public @interface Privileged {}
    

    Now, checking for this annotation’s existence in the calling code is achieved like this:

    public class Restricted {
        public Restricted() {
        int i = 2;
        while (true) {
            Class<?> caller = Reflection.getCallerClass(i++);
            if (caller == null) {
                throw new SecurityException();
            }
            if (caller.getAnnotation(Privileged.class) != null) {
                break;
            }
        }
    }
    
    1. The int parameter in the getCallerClass() method refers to the number of frames up the calling stack. Index 0 is Reflection.getCallerClass() itself, while index 1 is our restricted constructor, so that real work should begin at 2.
    2. The algorithm is to search up the stack until either the whole stack has been browsed and no privileged code has been found or stop when the matching annotation is found. In the former case, throw an exception, in the latter, do the job as expected.
    3. Of course, this algorithm shouldn't be hard-coded but factorized in a aspect and injected at some determined pointcut (perhaps a @Restricted annotation?)

    Ok, but what use-case does this solve? Well, I’ve always thought about what requirements Hibernate (or JPA) put on your design. One of such requirement is to provide a no-arg constructor, for the framework to instantiate. After that, it can use setter or inject attributes directly. Unfortunately, this conflicts with my desire to provide immutable objects that have all mandatory parameters in the constructor. A basic solution would be to provide both constructors but document them accordingly (/** Do not use: this one is for Hibernate. */). However, to really enforce this rule, you’d probably need to use getCallerClass() with a check on an org.hibernate package.

    Beware that Oracle intended to remove this method in the next JDK. Again, do not use this at home, but it opens some interesting perspectives, doesn’t it? […evil laugh…]

    Download the above code in IntelliJ/Maven format here.

    Categories: Java Tags: hack