Os valores de atributos para componentes do Oracle ADF Faces podem ser definidos normalmente apenas no servidor. No entanto, vários componentes permitem que o desenvolvedor defina uma lista de atributos que podem ser definidos no cliente. O atributo unsecure desses componentes pode especificar uma lista como essa.

Atualmente, o único atributo que pode aparecer dentro do atributo unsecure é disabled e permite que o cliente defina quais componentes estão habilitados e quais não estão. Nunca é uma boa ideia deixar que o cliente controle os valores de atributos que só devem ser configuráveis no servidor.

Exemplo: O código a seguir demonstra um componente inputText que coleta informações de senha do usuário e usa o atributo unsecure.

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

Os cookies são estritamente um mecanismo HTTP, de acordo com a RFC 2109. Não deve haver expectativa razoável de que eles trabalhem para protocolos que não sejam HTTP, incluindo file://. Não está claro qual deve ser seu comportamento e quais regras de compartimentalização de segurança devem ser aplicadas. Por exemplo, os arquivos HTML baixados para o disco local da Internet compartilham os mesmos cookies que qualquer código HTML instalado localmente?

O middleware ASP.NET Core que não é adicionado ao pipeline de middleware na ordem correta não funcionará conforme o esperado, deixando um aplicativo aberto a vários problemas de segurança.

Exemplo 1: O método UseCookiePolicy() adiciona o middleware de política de cookie ao pipeline de middleware, permitindo políticas de cookie personalizadas. Quando especificado na ordem errada, como mostrado, qualquer política de cookie indicada pelo programador será ignorada.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseCookiePolicy();
...

O middleware ASP.NET Core que não é adicionado ao pipeline de middleware na ordem correta não funcionará conforme o esperado, deixando um aplicativo aberto a vários problemas de segurança.

Exemplo 1: O método UseHttpsRedirection() adiciona o middleware de redirecionamento HTTPS ao pipeline de middleware, que permite o redirecionamento de solicitações HTTP não seguras para uma solicitação HTTPS segura. Quando especificado na ordem errada, conforme mostrado, nenhum redirecionamento HTTPS significativo ocorrerá antes de processar a solicitação por meio do middleware listado antes do redirecionamento. Isso permitirá que as solicitações HTTP sejam processadas pelo aplicativo antes de serem redirecionadas para a conexão HTTPS segura.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

O middleware ASP.NET Core que não é adicionado ao pipeline de middleware na ordem correta não funcionará conforme o esperado, deixando um aplicativo aberto a vários problemas de segurança.

Exemplo 1: O método UseHttpLogging() adiciona middleware de registro em log HTTP ao pipeline de middleware que permite que os componentes de middleware sejam registrados em log. Quando especificado na ordem errada, conforme mostrado, nenhum middleware adicionado ao pipeline antes da chamada para UseHttpLogging() será registrado em log.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

Exemplo 2: O método UseWC3Logging() adiciona o middleware de registro em log do W3C ao pipeline de middleware que permite que os componentes de middleware sejam registrados em log. Quando especificado na ordem errada, conforme mostrado, nenhum middleware adicionado ao pipeline antes da chamada para UseWC3Logging() será registrado em log.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

As ações do controlador ASP.NET MVC que modificam dados gravando, atualizando ou excluindo podem se beneficiar da restrição de aceitar um dos seguintes verbos HTTP: Post, Put, Patch ou Delete. Isso aumenta a dificuldade de falsificação de solicitação entre sites, pois o clique acidental de links não fará com que a ação seja executada.

A ação de controlador a seguir aceita qualquer verbo por padrão e pode ser suscetível a falsificação de solicitações entre sites:

public ActionResult UpdateWidget(Model model)
{
  // ... controller logic
}

Usar uma classe de modelo que possui propriedades obrigatórias (marcadas com o atributo [Required]) e propriedades opcionais (não marcadas com o atributo [Required]) pode provocar problemas quando um invasor comunica uma solicitação que contém mais dados que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo.

O fato de haver níveis combinados de exigência sem a comunicação explícita de quais parâmetros devem ser associados a modelos pode indicar que existem propriedades de modelo para uso interno, mas que essas propriedades podem ser controladas por um invasor.

O código a seguir define uma possível classe de modelo que tem propriedades com [Required] e propriedades sem [Required]:

public class MyModel
{
    [Required]
    public String UserName { get; set; }

    [Required]
    public String Password { get; set; }

    public Boolean IsAdmin { get; set; }
}

Se qualquer parâmetro opcional puder alterar o comportamento de um aplicativo, talvez um invasor seja capaz de realmente mudar esse comportamento comunicando um parâmetro opcional em uma solicitação.

Usar uma classe de modelo que possui propriedades obrigatórias não anuláveis (marcadas com o atributo [Required]) pode provocar problemas quando um invasor comunica uma solicitação que contém menos dados do que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo.

Se um modelo tiver um parâmetro obrigatório não anulável e um invasor não comunicar esse parâmetro em uma solicitação -- ou seja, se o invasor usar um ataque under-posting --, a propriedade terá o valor padrão (geralmente zero), que atenderá ao atributo de validação [Required]. Isso pode provocar o comportamento inesperado do aplicativo.

O código a seguir define uma classe de modelo possível que possui uma enumeração obrigatória não anulável:

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

Se uma classe de modelo tiver a propriedade obrigatória e for do tipo de um membro opcional de uma classe de modelo pai, ela poderá ser suscetível a ataques under-posting se um invasor comunicar uma solicitação contendo menos dados que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo, incluindo submodelos.

Se um submodelo for opcional -- ou seja, se o modelo pai tiver uma propriedade sem o atributo [Required] -- e se um invasor não comunicar esse submodelo, então a propriedade pai terá um valor null, e os campos obrigatórios do modelo filho não serão confirmados pela validação de modelo. Essa é uma das formas de ataque under-posting.

Considere as seguintes definições de classe de modelo:

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

Se um invasor não comunicar um valor para a propriedade ParentModel.Child, a propriedade ChildModel.RequiredProperty terá um [Required] não confirmado. Isso pode produzir resultados inesperados e indesejáveis.

De acordo com a política da Apple, o aplicativo deve sempre explicar aos usuários por que suas impressões digitais são necessárias. Não fazer isso pode confundir o usuário ou mesmo fazer com que o aplicativo seja rejeitado na AppStore.

Exemplo 1: O código a seguir usa a ID de toque para autenticar o usuário, mas não fornece um motivo localizado que explique porque a autenticação é necessária:

    [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics localizedReason:nil
        reply:^(BOOL success, NSError *error) {
            if (success) {
                NSLog(@"Auth was OK");
            } 
    }];

Mesmo que o Castor crie um bloqueio em um objeto, ele não impede que outros threads leiam ou gravem nele. Consultas somente leitura também são cerca de 7 vezes mais rápidas em comparação ao modo compartilhado padrão.

Exemplo 1: O exemplo a seguir especifica o modo de consulta como SHARED, o que permite acesso de leitura e gravação.

results = query.execute(Database.SHARED);

Por padrão, o Castor executa consultas no modo compartilhado. Como o modo compartilhado permite o acesso de leitura e gravação, não está claro para que tipo de operação a consulta se destina. Se o objeto for ser usado em um contexto somente leitura, o acesso compartilhado adicionará sobrecarga de desempenho desnecessária.

Exemplo 1: O exemplo a seguir não especifica um modo de consulta.

results = query.execute();    //missing query mode

Em algum momento na carreira do todos os desenvolvedores .NET, surge um problema que parece ser tão misterioso, impenetrável e impermeável a depurações que parece não haver nenhuma alternativa a não ser culpar o coletor de lixo. Especialmente quando o bug está relacionado ao tempo e ao estado, pode haver uma pitada de evidência empírica para apoiar essa teoria: inserir uma chamada em GC.Collect() às vezes parece fazer com que o problema desapareça.

Em quase todos os casos que temos visto, chamar GC.Collect() é a coisa errada a se fazer. Na verdade, chamar GC.Collect() pode causar problemas de desempenho isso for feito com demasiada frequência.

Em algum momento na carreira do todos os desenvolvedores Java, surge um problema que parece ser tão misterioso, impenetrável e impermeável a depurações que parece não haver nenhuma alternativa a não ser culpar o coletor de lixo. Especialmente quando o bug está relacionado ao tempo e ao estado, pode haver uma pitada de evidência empírica para apoiar essa teoria: inserir uma chamada em System.gc() às vezes parece fazer com que o problema desapareça.

Em quase todos os casos que temos visto, chamar System.gc() é a coisa errada a se fazer. Na verdade, chamar System.gc() pode causar problemas de desempenho isso for feito com demasiada frequência.

Ao comparar objetos, os desenvolvedores geralmente desejam comparar propriedades de objetos. No entanto, chamar equals() em uma classe (ou qualquer superclasse/interface) que não implemente equals() explicitamente resulta em uma chamada para o método equals() herdada de java.lang.Object. Em vez de comparar campos membros de objetos ou outras propriedades, o Object.equals() compara duas instâncias de objeto para ver se elas são iguais. Embora existam usos legítimos de Object.equals(), muitas vezes isso é uma indicação de um código com bug.

Exemplo 1:

public class AccountGroup
{
	private int gid;

	public int getGid()
	{
		return gid;
	}

	public void setGid(int newGid)
	{
		gid = newGid;
	}
}
...
public class CompareGroup
{
	public boolean compareGroups(AccountGroup group1, AccountGroup group2)
	{
		return group1.equals(group2);   //equals() is not implemented in AccountGroup
	}
}

A Especificação da Linguagem Java afirma que é uma boa prática um método finalize() chamar super.finalize() [1].

Exemplo 1: O seguinte método omite a chamada para super.finalize().

protected void finalize() {
  discardNative();
}

Integridade do código: Problemas de Assinatura de Método Serializável Incorreta ocorrem quando uma classe serializável cria uma função de serialização ou desserialização, mas não segue as assinaturas corretas:

  private void writeObject(java.io.ObjectOutputStream out) throws IOException;
  private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException;
  private void readObjectNoData() throws ObjectStreamException;

O desvio de assinaturas de método exibidas pela serialização pode significar que o método nunca será chamado durante a serialização/desserialização, provocando serializações/desserializações incompletas, ou pode significar que um código não confiável pode obter acesso aos objetos.
No caso em que existem exceções não lançadas, isso pode significar que a serialização/desserialização falhará e travará o aplicativo ou que ela até mesmo pode falhar silenciosamente de forma que os objetos possam ser apenas parcialmente construídos corretamente, levando a falhas que podem ser extremamente difíceis de depurar. O chamador deve capturar essas exceções de forma que a serialização/desserialização incorreta possa ser tratada adequadamente sem travamentos ou objetos parcialmente construídos.

Encaminhar um HttpServletRequest, redirecionar uma HttpServletResponse ou descarregar o fluxo de saída do servlet faz com que o fluxo associado seja confirmado. Quaisquer redefinições de buffer ou confirmações de fluxo subsequentes, como descarregamentos ou redirecionamentos adicionais, resultarão em IllegalStateExceptions.

Além disso, servlets Java permitem que dados sejam gravados no fluxo de resposta usando ServletOutputStream ou PrintWriter, mas não ambos. Chamar getWriter() depois de ter chamado getOutputStream(), ou vice-versa, também causará uma IllegalStateException.



Em tempo de execução, uma IllegalStateException impede que o manipulador de resposta seja executado até sua conclusão, eliminando eficientemente a resposta. Isso pode causar instabilidade no servidor, o que é um sinal de um servlet inadequadamente aplicado.

Exemplo 1: O código a seguir redireciona a resposta do servlet após o descarregamento do seu buffer de fluxo de saída.

public class RedirectServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
        ...
        OutputStream out = res.getOutputStream();
        ...
        // flushes, and thereby commits, the output stream
        out.flush();
        out.close();        // redirecting the response causes an IllegalStateException
        res.sendRedirect("http://www.acme.com");
    }
}

Exemplo 2: Por outro lado, o código a seguir tenta gravar e descarregar o buffer de PrintWriter depois que a solicitação foi encaminhada.

public class FlushServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
        ...
        // forwards the request, implicitly committing the stream
        getServletConfig().getServletContext().getRequestDispatcher("/jsp/boom.jsp").forward(req, res);
        ...

        // IllegalStateException; cannot redirect after forwarding
        res.sendRedirect("http://www.acme.com/jsp/boomboom.jsp");

        PrintWriter out = res.getWriter();

        // writing to an already-committed stream will not cause an exception,
        // but will not apply these changes to the final output, either
        out.print("Writing here does nothing");

        // IllegalStateException; cannot flush a response's buffer after forwarding the request
        out.flush();
        out.close();
    }
}

Na maioria dos casos, a configuração do cabeçalho Content-Length de um pedido indica que um programador está interessado na
comunicação do tamanho dos dados POST enviados ao servidor. No entanto, esse cabeçalho deverá ser 0 ou um
número inteiro positivo.

Exemplo 1: O código a seguir definirá um Content-Length incorreto.

  URL url = nova URL("http://www.exemplo.com");
  HttpURLConnection huc = (HttpURLConnection)url.openConnection();
  huc.setRequestProperty("Content-Length", "-1000");

Na maioria dos casos, uma chamada para toString() em um array indica que um desenvolvedor está interessado em retornar o conteúdo do array como um String. No entanto, uma chamada direta para toString() em um array retornará um valor de string contendo o tipo do array e o código hash na memória.
Exemplo 1: O seguinte código gerará [Ljava.lang.String;@1232121.

String[] strList = new String[5];
...
System.out.println(strList);