Weak SecurityManager Check: Overridable Method

Nenhum método não final que realiza verificações de segurança pode ser substituído de forma a ignorar as verificações de segurança.

Se um método for substituído por uma classe filho, esta poderá ignorar verificações de segurança na classe pai.
Exemplo 1: No código a seguir, doSecurityCheck() realiza uma verificação de segurança e pode ser substituído por uma classe filha.

public class BadSecurityCheck {
    private int id;

    public BadSecurityCheck() {
        doSecurityCheck();
        id = 1;
    }
    protected void doSecurityCheck() {
        SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
            sm.checkPermission(new SomePermission("SomeAction"));
        }
    }
}

Nesse exemplo, se a permissão SecurityManager não for permitida, será lançada uma exceção SecurityException, que é uma exceção de tempo de execução, e interromperá a execução do programa. Como BadSecurityCheck não é final e o método doSecurityCheck() é protected e não final, isso significa que essa classe pode ser uma subclasse para substituir essa função.

Exemplo 2: No seguinte código, doSecurityCheck() é substituído por uma subclasse:

public class EvilSubclass extends BadSecurityCheck {
    private int id;

    public EvilSubclass() {
        super();
    }
    protected void doSecurityCheck() {
        //do nothing
    }
}

Quando EvilSubclass é instanciado, o construtor chama primeiro super() para invocar o construtor da superclasse. Por sua vez, ele chama a função doSecurityCheck(), mas o Java procurará primeiro pela função na subclasse antes de procurar na superclasse, invocando assim o método controlado pelo invasor, que ignora a verificação de segurança, de modo que id ainda será definido como 1.