Los paquetes PL/SQL pueden ser AUTHID DEFINER o AUTHID CURRENT_USER. Las funciones y los procedimientos de un paquete con los derechos del definidor se ejecutan con los privilegios del usuario que define el paquete. De este modo se podrán implementar las actualizaciones y obtener acceso a datos específicos sin permitir el acceso a todo el contenido de las tablas o los esquemas. En un paquete con los derechos del invocador o AUTHID CURRENT_USER, las funciones y los procedimientos se ejecutan con los privilegios del usuario que los invoca. Así, un usuario no tendrá acceso a los datos a los que aún no podía acceder. Si la cláusula AUTHID no se proporciona, el paquete utilizará los derechos del definidor de forma predeterminada.

Por lo general, los paquetes se definen mediante SYS u otro usuario con privilegios elevados, lo cual hace que las vulnerabilidades de seguridad del código sean potencialmente más peligrosas.

Determinadas operaciones de Android necesitan permisos. La aplicación debe solicitar los permisos en el momento de la instalación enumerándolos en el archivo AndroidManifest.xml mediante las etiquetas <uses-permission/>. Si no se han solicitado los permisos necesarios, las operaciones que requieren esos permisos producirán errores a la vez. En algunos casos, se devuelve un java.lang.SecurityException a la aplicación. En otras ocasiones, las operaciones producen un error en silencio sin una excepción.

Ejemplo 1: el siguiente código envía un mensaje SMS basado en texto.

sms.sendTextMessage(recipient, null, message, PendingIntent.getBroadcast(SmsMessaging.this, 0, new Intent(ACTION_SMS_SENT), 0), null);

Esta API necesita el permiso android.permission.SEND_SMS. Si la aplicación no solicita este permiso en el archivo manifest, la aplicación no podrá enviar un mensaje SMS.

Determinadas operaciones de Android necesitan permisos. La aplicación debe solicitar los permisos en el momento de la instalación enumerándolos en el archivo AndroidManifest.xml mediante las etiquetas <uses-permission/>. Si no se han solicitado los permisos necesarios, las operaciones que requieren esos permisos producirán errores a la vez. En algunos casos, se devuelve un java.lang.SecurityException a la aplicación. En otras ocasiones, las operaciones producen un error en silencio sin una excepción.

Ejemplo 1: el siguiente código lee información de los contactos almacenada en el dispositivo.

Cursor cursor = getContentResolver().query(ContactsContract.Contacts.CONTENT_URI, null, null, null, null);

Para leer los datos de este proveedor de contenido, es necesario disponer del permiso android.permission.READ_CONTACTS. Si la aplicación no solicita este permiso en el archivo manifest, esta no podrá leer la información de los contactos.

Determinadas operaciones de Android necesitan permisos. La aplicación debe solicitar los permisos en el momento de la instalación enumerándolos en el archivo AndroidManifest.xml mediante las etiquetas <uses-permission/>. Si no se han solicitado los permisos necesarios, las operaciones que requieren esos permisos producirán errores a la vez. En algunos casos, se devuelve un java.lang.SecurityException a la aplicación. En otras ocasiones, las operaciones producen un error en silencio sin una excepción.

Ejemplo 1: el siguiente código envía una finalidad con la acción android.provider.Telephony.SMS_RECEIVED.

    Intent i = new Intent("android.provider.Telephony.SMS_RECEIVED");
    context.sendBroadcast(i);

Para enviar esta finalidad, se debe disponer del permiso android.permission.BROADCAST_SMS. Si la aplicación no solicita este permiso en el archivo manifest, la aplicación no podrá enviar la finalidad.

Los principios de codificación segura abogan por hacer que los especificadores de acceso sean tan restrictivos como sea posible. Un método con un especificador de acceso public indica que todo el código externo tiene permiso para llamarlo. Los métodos públicos que realizan acciones privilegiadas pueden ser peligrosos cuando el código se comparte en bibliotecas o en entornos donde el código puede entrar de forma dinámica en el sistema (por ejemplo, inserción de código, inclusión de archivos peligrosos, carga de archivos, etc.).

Ejemplo 1: en el código siguiente, doPrivilegedOpenFile() se declara public y realiza una operación privilegiada.

public static void doPrivilegedOpenFile(final String filePath) {
final BadFileNamePrivilegedAction pa = new BadFileNamePrivilegedAction(filePath);

FileInputStream fis = null;
...
fis = (FileInputStream)AccessController.doPrivileged(pa);
...
}

Si utiliza la opción ALL PRIVILEGES o ALL otorgará al usuario todos los permisos que se pueden aplicar a un objeto. El programador no puede ser consciente de todos los privilegios que se le conceden.

Ejemplo 1: Un administrador puede que desee proporcionar a un usuario la capacidad de actualizar los datos en el procedimiento.

GRANT ALL ON employees TO john_doe;

Además de la posibilidad de seleccionar, actualizar, agregar y quitar filas, john_doe dispone ahora de permisos para cambiar la definición de la tabla.

Algunas funciones permiten a un programador especificar un valor explícito sobre si el permiso se concede o no. Esto puede ser objeto de abuso para infringir los deseos del usuario y asumir que se concedió el permiso.

Ejemplo 1: El siguiente código pide permiso para utilizar la ubicación del usuario en Android mientras se usa WebView; sin embargo, utiliza la ubicación del usuario tanto si se concede permiso para hacerlo como si no. Esto se logra invocando de forma manual la devolución de llamada con true para especificar que el permiso se concedió:

public void onGeolocationPermissionsShowPrompt(String origin, GeolocationPermissions$Callback callback){
  super.onGeolocationPermissionsShowPrompt(origin, callback);
  callback.invoke(origin, true, false);
}

Una aplicación solo debe tener los permisos mínimos requeridos para su correcta ejecución. Los permisos adicionales pueden disuadir a los usuarios de instalar la aplicación. Este permiso puede ser innecesario para este programa.

Las aplicaciones de Spring Boot se pueden configurar para implementar actuadores, que son puntos finales REST que permiten a los usuarios supervisar diferentes aspectos de la aplicación. Hay diferentes actuadores integrados que pueden exponer datos confidenciales y están etiquetados como "sensibles". De forma predeterminada, todos los puntos finales HTTP sensibles están protegidos de modo que solo los usuarios con el rol ACTUATOR pueden acceder a ellos.

Esta aplicación está deshabilitando el requisito de autenticación de puntos finales sensibles:

Ejemplo 1:

management.security.enabled=false

O marcando los puntos finales sensibles como no sensibles:

Ejemplo 2:

endpoints.health.sensitive=false

O bien, un actuador personalizado está establecido como no sensible:

@Component
public class CustomEndpoint implements Endpoint<List<String>> {

    public String getId() {
        return "customEndpoint";
    }

    public boolean isEnabled() {
        return true;
    }

    public boolean isSensitive() {
        return false;
    }

    public List<String> invoke() {
        // Custom logic to build the output
        ...
    }
}

Spring Boot permite a los desarrolladores habilitar características relacionadas con el administrador para la aplicación mediante la especificación de la propiedad spring.application.admin.enabled. Esto expone SpringApplicationAdminMXBean en la plataforma MBeanServer. Los desarrolladores podrían usar esta característica para administrar la aplicación de Spring Boot de forma remota; sin embargo, esta característica expone una superficie de ataque adicional en forma de un punto final JMX remoto. Dependiendo de la configuración de MBeanServer, el objeto MBean pueden exponerse de forma local o remota y puede requerir autenticación o no. En el peor de los casos, los atacantes podrán administrar la aplicación de forma remota, incluso cerrarla sin necesidad de autenticación. En el mejor de los casos, el servicio será tan seguro como las credenciales utilizadas para proteger el servidor.

Nota: Si usa una versión de JRE vulnerable a CVE-2016-3427 (corregida en Java 8 Update 91, abril de 2016), un atacante podrá pasar cualquier objeto Java serializado como credenciales, lo que puede llevar a la ejecución de código arbitrario cuando la JVM remota lo deserializa.

La aplicación de Spring Boot tiene habilitada la característica DevTools. DevTools incluye un conjunto adicional de herramientas que pueden hacer que la experiencia de desarrollo de aplicaciones sea un poco más agradable, pero no se recomienda su uso en aplicaciones en un entorno de producción. Como se indica en la documentación oficial de Spring Boot: "Habilitar spring-boot-devtools en una aplicación remota es un riesgo para la seguridad. Nunca se debe habilitar en una implementación de producción".

El actuador de apagado permite a los usuarios autenticados cerrar la aplicación. Aunque está configurado de forma predeterminada como un punto final sensible y, por lo tanto, se necesita autenticación para usarlo, no es recomendable habilitarlo sin una razón sólida, ya que las credenciales pueden ser débiles o la configuración de la aplicación se puede modificar para marcar el actuador como no sensible.

Ejemplo 1: Una aplicación de Spring Boot está configurada para implementar el actuador de apagado:

endpoints.shutdown.enabled=true

Spring Security se configura con una directiva general demasiado permisiva con la cual se permite el acceso a las solicitudes que no coinciden con ninguna expresión de seguridad.

Ejemplo 1: El siguiente código establece una configuración de Spring Security en la que la opción predeterminada es permitir todas las solicitudes sin coincidencias:

	<http auto-config="true">
        ...
        <intercept-url pattern="/app/admin" access="ROLE_ADMIN" />
        <intercept-url pattern="/**" access="permitAll" />
	</http>

Si bien esta es una configuración segura en la actualidad, es posible que se agreguen nuevos puntos finales privados a la aplicación en el futuro. Si los desarrolladores olvidan actualizar la directiva de seguridad, la regla general predeterminada permitirá el acceso público a los puntos finales nuevos.

Spring Security define encabezados de seguridad predeterminados para proteger la aplicación. Los encabezados de seguridad predeterminados que inyecta Spring Security son:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

Estos son encabezados razonables que protegen la aplicación. No deshabilite estos encabezados a menos que los reemplace por valores más restrictivos.

Ejemplo 1: El siguiente código deshabilita los encabezados predeterminados de Spring Security:

	<http auto-config="true">
        ...
        <headers disabled="true"/>
        ...
	</http>

Spring Security tomó prestadas las expresiones de ruta Ant para especificar la forma de proteger los puntos finales.

Ejemplo 1: En el siguiente ejemplo, todo punto final que coincide con la expresión de ruta Ant "/admin" requiere privilegios de administrador para obtener acceso:

	<http auto-config="true">
        ...
        <intercept-url pattern="/app/admin" access="ROLE_ADMIN" />
        ...
        <intercept-url pattern="/**" access="permitAll" />
	</http>

Sin embargo, si el punto final protegido es uno de Spring MVC, un atacante puede hacer uso indebido de las funciones de negociación de contenido de Spring MVC para eludir este control. Con Spring MVC, los usuarios pueden especificar la forma en que desean que se proporcione el recurso. Para ello, pueden utilizar el encabezado Accept o especificar el tipo de contenido deseado mediante una extensión. Por ejemplo, para solicitar el recurso /admin como un documento JSON, puede enviar la solicitud a /admin.json.
Las expresiones de ruta Ant no representan extensiones de negociación de contenido; por lo tanto, la solicitud no coincide con la expresión /admin y no se protege el punto final.

Spring Security emplea un control de acceso basado en expresiones con el que los desarrolladores pueden definir un conjunto de comprobaciones que se deben aplicar a cada solicitud. Para determinar si se debe aplicar el control de acceso a una solicitud, Spring Security intenta comparar la solicitud con el buscador de coincidencias definido para cada comprobación de seguridad. Si la solicitud coincide, se aplica le el control de acceso. Existe un buscador de coincidencias especial con el cual es posible comparar todas las solicitudes: anyRequest(). Si no se define una comprobación de reserva con el buscador de coincidencias anyRequest(), los puntos finales pueden quedar desprotegidos.

Ejemplo 1: El siguiente código establece una configuración de Spring Security en la que no se define una comprobación de reserva:

	<http auto-config="true">
        <intercept-url pattern="/app/admin" access="ROLE_ADMIN" />
        <intercept-url pattern="/" access="permitAll" />
	</http>

En el Example 1 anterior, es posible que los puntos finales actuales o futuros, como /admin/panel, queden desprotegidos.

Spring Security incluye un firewall de HTTP con el que es posible corregir las solicitudes con caracteres potencialmente malintencionados para proteger la aplicación. Para lograr esto, Spring incluye HttpFirewall en su FilterChainProxy, de modo que las solicitudes se procesan antes de pasar por la cadena de filtros. Spring Security utiliza la implementación de StrictHttpFirewall de forma predeterminada.


Ejemplo 1: El siguiente código flexibiliza la directiva de firewall para permitir los caracteres %2F y ;:

    <beans:bean id="httpFirewall" class="org.springframework.security.web.firewall.StrictHttpFirewall" p:allowSemicolon="true" p:allowUrlEncodedSlash="true"/>

Cuando se permiten caracteres malintencionados, se pueden presentar vulnerabilidades si estos caracteres se procesan de forma incorrecta o incoherente. Por ejemplo, cuando se permite el punto y coma, se habilitan parámetros de ruta (según se define en RFC 2396) que los servidores web front-end, como NGINX, y los servidores de aplicaciones, como Apache Tomcat, no procesan de forma coherente. Estas incoherencias se pueden utilizar para provocar ataques de escalado de directorios u omisiones de control de acceso.

Cualquier servidor que contenga información confidencial o funcionalidad privilegiada, como un panel de administración remota, debe requerir autenticación para acceder. Si este no es el caso, un atacante puede robar información confidencial o tomar el control de un host objetivo solo con adivinar nombres de usuarios comunes.

El cliente puede utilizar el método NoneAuth de autenticación para determinar los métodos de autenticación disponibles.

Ejemplo 1: El siguiente código Paramiko intenta autenticarse con el servidor utilizando la solicitud de autenticación "none".

    client = SSHClient()
    client.connect(host, port, auth_strategy=NoneAuth("user"))

Los programas implementados fuera de la infraestructura de red de una empresa pierden las garantías internas de seguridad en la transmisión de datos. Un atacante que resida en una red compartida puede espiar el tráfico no cifrado.

Los servidores de MongoDB no autenticados pueden ser el objetivo de atacantes a fin de comprometer los datos que contiene y, según la versión de MongoDB, acceder a su red interna, poniendo en riesgo el servidor.

Se pueden utilizar distintos ataques contra un servidor de MongoDB para ejecutar código arbitrario en su sistema operativo subyacente. Por ejemplo, existían vulnerabilidades en el pasado que permitían a los atacantes utilizar la inyección de JavaScript del lado del servidor para ejecutar código remoto. Cuando se utilizan para almacenar objetos, un atacante también puede almacenar cargas de deserialización para distintos lenguajes como Java, Python, Ruby, PHP, etc., a fin de lograr la ejecución remota de código en el punto final que realiza la deserialización.

Tenga en cuenta que, incluso si el servidor de MongoDB no está expuesto externamente, un atacante externo todavía podría acceder a él o a la API de REST mediante una vulnerabilidad Server-Side Request Forgery en cualquier aplicación de la misma red. Por ejemplo, los servidores de MongoDB se pueden atacar mediante protocolos HTTP o Gopher.

El hecho de no proteger el puerto de MongoDB externamente puede tener un gran impacto en la seguridad. Por ejemplo, un atacante externo puede utilizar un único comando remove para suprimir todo el conjunto de datos. Recientemente se han dado casos de ataques malintencionados en instancias de MongoDB no protegidas que se ejecutaban abiertamente en Internet. En tales casos, los atacantes borraron la base de datos y solicitaron un rescate para restablecerla.