-
Notifications
You must be signed in to change notification settings - Fork 0
/
api.txt
122 lines (88 loc) · 11.3 KB
/
api.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
Diseño y/o securización de una API
0.- Introduccion
Tenemos los portales Web que son frotal web (FrontEnd), al cual navegamnos con URL desde un navegador Web (Mozilla FIrefoz, Chrome, Edge, IE, ..) por HTTP y obtenemos información representada en formato pagina Web.
cliente navegador -----/https/------- servidor Web URL https://www.hackingyseguridad.com/fichacliente.html?=34606534642
obtenemos respuesta en formato web
Las API se suelen utilizar para obetener datos/informacion, atacamos al Frontend pero obtenemos datos que obtenemos son de Backend a traves de conxector AJAX; bien consultando a la API por HTTP de forma directa con comando curl, APP POSTMAN, o de forma embebida en el codigo fuente HTML de un portal web FrontEnd.
La mayoria de las aplicaciones actuales APP ó APK de los moviles, por detras utilizan APIs para subir o bajar datos de una infraestructura remota. ( modelo Cliente - servidor )
cliente curl ------/https/--------- servidor api URI
curl -X POST -k https://api.hackingyseguridad.com:8080/api/rest/v1/consultatelefono?=34606534642/token=23214232323423
Headers
Accept application/json
Content-Type: application/x-www-form-urlencoded
X-Method-Override: PUT
sort=created_At_desc
Host: hackingyseguridad.com
Autorización: Bearer 2342fd23
Request Body:
action=finish¶ms={"orderNumber":"5","customerName":{"firstName":"Antonio","lastName":"Taboada"}}
obtenemos respuesta Json
SOAP: Protocolo simple de acceso a objetos, es un protocolo de mensajería basado en XML.
GraphQL: GraphQL es un lenguaje de consulta que permite a los usuarios conectarse e interactuar con fuentes de datos dispares a través de un único punto final API. Uuna solicitud aparentemente simple puede requerir un procesamiento posterior significativo o tener impactos de lectura/escritura de amplio alcance que violan los permisos de acceso.
WebSockets: los WebSockets permiten una comunicación bidireccional continua entre clientes y un servidor a través de una única conexión TCP. WebSockets no maneja la autenticación o el cifrado directamente, lo que significa que los desarrolladores deben utilizar TLS explícitamente y verificar la autorización.
gRPC:llamada a procedimiento remoto (RPC) que opera a través de HTTP/2 y facilita la comunicación de baja latencia entre servicios políglotas y clientes a escala. Al igual que SOAP, gRPC se basa en la serialización para transmitir datos, pero utiliza Protocol Buffers como mecanismo
cat fichero.josn \ jq
1.- Tipos de API, como funciona, tipo: REST, GraphQL, WebSocket, SOAP, JSON RPC, XML, HTTP, HTTPS.
API SOAP es un protocolo de acceso a objetos simples, la trasferencia de datos es XML a traves de HTTP/HTTPS
API REST en una arquitectura, trasferencia de estado respresetacional. La trasferencia de datos es por XML o JSON, a traves de HTTP
2.- Pruebas API con: Curl, POSTman, wget, apitest, ..
comando curl en consola linux curl -k https://ipinfo.io/80.58.61.250
postman https://www.postman.com/ desde PC Windows
https://apitest.dev/
3.- Servidor web de la API: Bastionado, actualizado con último parches estables, tanto si es Windows Server como Linux/UNIX, sin permitir en la conf explorar carpetas, sin banners ni información del fingerprint de los servicios visibles ( p.ej version Nginx,Apache(Linux) o IIS(Windows)), y evitar o securizar otros servicios accesibles: FTP, SSH, Telnet, puertos web de un Panel de Control, ..
4º.- Certificado digital, emitido por una CA entidad certificadora de confianza; Conocidas las claves de la CA /PKI por la mayoría de los navegadores web, curl, ..
5º.- Protocolos y cifrados recomendados. TLS 1.2, TLS 1.3 y cifrados de trasporte con combinacines AES > 128 ó superior y/o CHACHA20.
En las API el cifrado es vital, pues se podria interceptar todo el formato y datos que se envian y reciben
6.- Metodos HTTP: GET, POST, PUT, DELETE, .. y configuracion de cabeceras de seguridad HTTP, En las API este punto es importante:
El protocolo HTTP define una gran cantidad de métodos utilizamos en la construcción de servicios REST:
GET: Es utilizado únicamente para consultar información al servidor, muy parecidos a realizar un SELECT a la base de datos. No soporta el envío del payload
POST: Es utilizado para solicitar la creación de un nuevo registro, es decir, algo que no existía previamente, es decir, es equivalente a realizar un INSERT en la base de datos. Soporta el envío del payload.
PUT: Se utiliza para actualizar por completo un registro existente, es decir, es parecido a realizar un UPDATE a la base de datos. Soporta el envío del payload.
PATCH: Este método es similar al método PUT, pues permite actualizar un registro existente, sin embargo, este se utiliza cuando actualizar solo un fragmento del registro y no en su totalidad, es equivalente a realizar un UPDATE a la base de datos. Soporta el envío del payload
DELETE: Este método se utiliza para eliminar un registro existente, es similar a DELETE a la base de datos. No soporta el envío del payload.
HEAD: Este método se utilizar para obtener información sobre un determinado recurso sin retornar el registro. Este método se utiliza a menudo para probar la validez de los enlaces de hipertexto, la accesibilidad y las modificaciones recientes.
Hasta aquí los métodos más utilizados en la construcción de servicios REST con JAX-RS, sin embargo, existen algunos métodos más que son interesantes conocer, pues no los encontraremos al momento de depurar o analizar el tráfico de red.
CONNECT: Se utiliza para establecer una comunicación bidireccional con el servidor. En la práctica no es necesario ejecutarlo, si no el mismo API de HTTP se encarga de ejecutarlo para establecer la comunicación previo a lanzar alguna solicitud al servidor.
OPTIONS: Este método es utilizado para describir las opciones de comunicación para el recurso de destino. Es muy utilizado con CORS (Cross-Origin Resource Sharing) para validar si el servidor acepta peticiones de diferentes origines.
A pesar de que los métodos están diseñados para realizar ciertas acciones, la realidad es que nada impide que los utilices de forma errónea,
- la mayoria de los firewall WAF no permiten tráfico HTTP PUT ni DELETE por seguridad. Permitirlo conlleva permitir PUT o delete para todo el servicio API/WEB - Para evitar esta restricción, por las necesidades de REST y sin necesitad de activar estos metodos explicitamente, se puede enviar estas solicitudes con las cabeceras:
HTTP X-Method-Override o X-HTTP-Method-Override para pasar una solicitud PUT o DELETE de forma embebida sobre metodo http POST.
o x-method-override o x-http-method-override.
Configurar en el lado servidor cabeceras HTTP de seguridad en el servidor recomendadas: Strict-Transport-Security (HSTS), X-XSS-Protection, X-Content-Type-Option, Cache-Control, ..
7.- Métodos de autenticación y autorización: Modo de envío de credenciales. Autorización Ouath2
Una API puede ser:
Publica, cualquiera puede consulta a la API si conoce la sintaxis y obtener inforamcion
Privada, requiere autenticación con credenciales o un token temporal, para poder obetener daots
La autenticación API se puede realizar tambien a través de; Autenticación básica HTTP, configuración de clave de autenticación API, tokens de servidor IdP, identidad federada SAML, tokens de acceso API y OAuth con OpenID.
Tras autenticarnos, normalmente con unas credenciales email/usuario y clave/password, se genera un clodigo Token, que nos servira para hacer llamadas a la API con el como forma de autenticacion
Puede existir autenticación por certificado, en el lado Servidor hemos creado una clave privada y clave publica que solo es capaz de negociar con un cliente que tenga instalado un certificado, conozca la clave publica
- Autenticación WEB o API con credenciales usuario/crreo y clave/passwd, no AAA; utilizar credenciales seguras: mínimo 12 caracteres, recomendado 16, combinando letras, números, alguna mayúscula y algún carácter especial, para dotarla de la máxima seguridad. - Usuarios no predecibles. Evitar utilizar usuarios del tipo: Admin, administrador, user, antonio, 1234, … - Implementar en WEB / API bloqueos temporales del usuario y/o IP origen, ante ataques de fuerza bruta. - Si no es un WEB / API de acceso público, considerar filtrar con firewall access-list, para que solo este accesible desde determinados direccionamiento origen
OAuth2 usando OpenID Connect
OAuth 2.0 , que significa "Autorización abierta", es un estándar diseñado para permitir que un sitio web o una aplicación acceda a los recursos alojados por otras aplicaciones web en nombre de un usuario. Como característica de seguridad adicional, a menudo es normal, según los estándares de seguridad de la industria, que las organizaciones deleguen la autorización y/o autenticación de sus API a IdP (proveedores de identidad) de terceros. Para reforzar aún más la seguridad, se puede agregar una capa de identidad adicional en forma de Open Id Connect, un estándar que amplía OAuth2 con tokens de identificación.
8.- En el codigo de las paginas web evitar embeber APIs con “secretos” tokens o credenciales , en claro o codificadas en el código de nuestra Web. Tampoco dejar anotaciones del programador o información que se suele añadir durante el desarrollo del portal. - Si hay API s contra terceros, comprobar la información que exponen esas API, tokens, modo autenticación, información contenida en la sintaxis de la API, modo seguro estricto HTTPS, modo http GET, PUT, etc.., comprobar que información, el modo de comunicación, autenticación, ..
9.- Firewall: WAF: Considerar implementar un WAF, para restringir sintaxis no deseadas del API REST. WAF para revistar cabeceras HTTP, de suplantación IP origen.
Firewall capa 4, ACL access list IP para filtrar consumo de API. Spoof IP, Rate limit, peticiones API
Disponer de un BackUp del portal y un plan B, caso de caída o catástrofe con otro servidor en contingencia si no esta replicado en la plataforma de alojamiento donde vamos a publicar el portal web/api. AntiDDoS: Considerar configurar alertas y activar en la plataforma de AntiDDoS.
curl -X POST --http1.0 -vvv -k https://api.hackingyseguridad.com:8080/api/rest/v1/consultatelefono?=34606534642/token=23214232323423
-H "Accept application/json"
-H "Content-Type: application/x-www-form-urlencoded"
-H "X-Custom-IP-Authorization: 127.0.0.1" \
-H "X-HTTP-Method-Override: ACL" \
-H "X-Originating-IP: 127.0.0.1" \
-H "X-Forwarded-For: 127.0.0.1" \
-H "X-Forwarded-Host: 127.0.0.1" \
-H "X-Forwared-Host: 127.0.0.1" \
-H "X-Real-IP: 127.0.0.1" \
-H "X-Remote-IP: 127.0.0.1" \
-H "X-Remote-Addr: 127.0.0.1" \
-H "X-Client-IP: 127.0.0.1" \
-H "User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0" \
-H "Accept: text/html, applicattion/xhtml+xml, application/xml;q=0.9,*/*;q=0.8" \
-H "Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3" \
-H "Connection: keep-alive" \
-H 'X-Method-Override: PUT' \
-H "Request Body:
action=finish¶ms={"orderNumber":"5","customerName":{"firstName":"Antonio","lastName":"Taboada"}}
10º.- Hacer pruebas con la API, birate, carga, conexiones concurrentes, bandwicht; si se ha configurado algún servicio de mitigación de ataques AntiDDoS hacer pruebas de alertas y mitigación previas, hacer análisis hacking ético previo para comprobar que todo está acorde a todo lo descrito anterior.
http://www.hackingyseguridad.com
https://owasp.org/www-project-api-security/