
<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Seguridad &#8211; Programador Magento</title>
	<atom:link href="https://www.dinaweb.net/seguridad-magento/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.dinaweb.net</link>
	<description>Federico Chulilla &#124; Valencia / Teruel &#124; Tel.650594708</description>
	<lastBuildDate>Wed, 06 Jan 2021 16:50:59 +0000</lastBuildDate>
	<language>es</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=5.3.21</generator>
	<item>
		<title>Habilitar ReCaptcha en Magento 2</title>
		<link>https://www.dinaweb.net/habilitar-recaptcha-para-evitar-registros-falsos-en-magento-2/</link>
				<comments>https://www.dinaweb.net/habilitar-recaptcha-para-evitar-registros-falsos-en-magento-2/#respond</comments>
				<pubDate>Thu, 17 Sep 2020 15:14:00 +0000</pubDate>
		<dc:creator><![CDATA[Federico Chulilla]]></dc:creator>
				<category><![CDATA[Seguridad]]></category>

		<guid isPermaLink="false">https://www.dinaweb.net/?p=2390</guid>
				<description><![CDATA[Los registros SPAM en cualquier formulario es algo muy habitual si no se toman medidas. Cuando un bot detecta una url sin restricciones preparate para registros o emails SPAM. Y Magento no es diferente. Este CMS tiene diferentes formularios en su estructura como son la suscripción al newsletter, registro de cliente o formulario de contacto... <a class="more-link" href="https://www.dinaweb.net/habilitar-recaptcha-para-evitar-registros-falsos-en-magento-2/">Continuar leyendo <span class="meta-nav">→</span></a>]]></description>
								<content:encoded><![CDATA[
<p>Los registros SPAM en cualquier formulario es algo muy habitual si no se toman medidas. Cuando un bot detecta una url sin restricciones preparate para <strong>registros o emails SPAM</strong>.</p>



<p>Y Magento no es diferente. Este CMS tiene diferentes formularios en su estructura como son la suscripción al newsletter, registro de cliente o formulario de contacto que son carne de cañón para los insistentes bots.</p>



<p>Si tenemos registros fake en principio no supone un problema de seguridad. Pero si nos va a ensuciar nuestra base de datos, entorpecer el trabajo diario y puede derivar en problemas o advertencias por parte del <strong>hosting</strong> por enviar emails a cuentas inexistentes o fraudulentos.</p>



<p>Por todo esto, es necesario poner medidas para que nuestra tienda no se convierta en un coladero de SPAM. Algunas de estas medidas son:</p>



<ul><li>Bloquear IP. Ips rusas, chinas, o sudeste asiático son comunes. Pero bloquear una determinada IP no excluye que mañana venga de otra IP distinta.</li><li>Boquear User Agent. Puede ser útil para limitar molestas arañas de rastreo. ¡Pero cuidado con blouear el robot de Google!</li><li>Habilitar la confirmación de email. No evita el registro en la bbdd pero si que ese usuario este activo. La desventaja es que sólo sirve para el formulario de registro y obligas a los usuarios a dar un paso más en el proceso.</li><li>Reducir el número de caracteres para ciertos campos (en el caso del registro).  En la bbdd podemos especificar que longitud máxima tendrá el campo «Nombre» y «Contraseña» para el cliente. Los bots suelen añadir mucha porquería en los campos del formulario por lo que si indicamos que la longitud de nombre y apellido no pueden ser mayor a 40 carácteres puede parar su molestas acciones. Esto se hace desde la tabla  <strong>customer_eav_attribute</strong>&nbsp; y modificamos  <em>attribute_id=5</em> (nombre)  y  <em>attribute_id=</em>7 (apellido) de esto:<br> a:2:{s:15:»max_text_length»;i:255;s:15:»min_text_length»;i:1;} <br>a<br><code>a:2:{s:15:"max_text_length";i:40;s:15:"min_text_length";i:1;}</code></li><li>Captcha. Tanto Magento 1 como Magento 2 tienen la opción de habilitar un campo captcha en determinados lugares. Pero en ciertas ocasiones los malditos bots se saltan este campo.</li><li><strong>Google Recaptcha</strong>. Para añadir este servicio de Google en Magento 1 era necesario añadir una extensión que nos añadiera esta funcionalidad. En Magento 2 ya viene por defecto.</li></ul>



<h2>Configurar Google Recaptcha para Magento 2</h2>



<p>Primero iremos a  <a href="https://www.google.com/recaptcha/admin">Google reCAPTCHA  </a>para generar un nuevo dominio con sus claves. Añadiremos un dominio con una etiqueta cualquiera.</p>



<p>Podremos escoger entre estos servicios:</p>



<ul><li><em>reCAPTCHA v3 Invisible</em></li><li><em>reCAPTCHA v2 Invisible</em></li><li><em>reCAPTCHA v2 (“No soy un robot”)</em></li></ul>



<p>Una vez guardado nos generará dos claves que deberemos guardar para configurar en nuestro admin Magento:</p>



<p>Vamos a  <strong>Stores</strong> &gt; <em>Settings</em> &gt; <strong>Configuration</strong> </p>



<p> En el panel de la izquierda, en la sección Security, vamos a google <strong>reCAPTCHA Admin Panel</strong></p>



<p>La versión Invisible es interesante porque sólo muestra el captcha en el caso de levantar sospechas de que no es un humano el que está al otro lado. Esto ayuda a la usabilidad de la tienda. Para usar reCAPTCHA v3 Invisible, expandimos su apartado y rellenamos y configuramos los datos que nos pide.</p>



<p>Los más importantes para que funcione son  <strong>Google API Website Key</strong>  y  <strong>Google API Secret Key</strong> , datos anteriormente generados al generar nuestra cuenta en Google Recaptcha.</p>



<h2>Google Recaptcha para Magento 1</h2>



<p>Si tienes Magento 1 recomiendo usar la extensión Magento Google Invisible Captcha de Amasty que funciona muy bien. </p>
]]></content:encoded>
							<wfw:commentRss>https://www.dinaweb.net/habilitar-recaptcha-para-evitar-registros-falsos-en-magento-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
							</item>
		<item>
		<title>¿Cómo afecta el RGPD a mi tienda online Magento?</title>
		<link>https://www.dinaweb.net/rgpd-magento/</link>
				<comments>https://www.dinaweb.net/rgpd-magento/#respond</comments>
				<pubDate>Wed, 30 May 2018 18:06:37 +0000</pubDate>
		<dc:creator><![CDATA[Federico Chulilla]]></dc:creator>
				<category><![CDATA[Seguridad]]></category>

		<guid isPermaLink="false">http://www.dinaweb.net/?p=1988</guid>
				<description><![CDATA[¿Tu tienda recoge y almacena datos de ciudadanos de la Unión Europea? Si la respuesta es afirmativa, estará afectada por el nuevo reglamento. En pocas palabras, con un simple formulario de contacto ya estaremos manipulando datos del usuario. Ampliando el ejemplo anterior si, en nuestro ecommerce, los usuarios: pueden suscribirse al newsletter pueden enviar un... <a class="more-link" href="https://www.dinaweb.net/rgpd-magento/">Continuar leyendo <span class="meta-nav">→</span></a>]]></description>
								<content:encoded><![CDATA[<p><b>¿Tu tienda recoge y almacena datos de ciudadanos de la Unión Europea? Si la respuesta es afirmativa, estará afectada por el nuevo reglamento</b>. En pocas palabras, con un simple formulario de contacto ya estaremos manipulando datos del usuario.</p>
<p>Ampliando el ejemplo anterior si, en nuestro ecommerce, los usuarios:</p>
<ul>
<li>pueden suscribirse al newsletter</li>
<li>pueden enviar un formulario de presupuesto</li>
<li>pueden finalizar pedido en tu tienda</li>
<li>hacen comentarios de producto</li>
</ul>
<p>deberemos adaptarnos a la <span class="st">nueva <em>ley</em> de protección de datos.</span></p>
<p>Incluso si no tuviéramos nada de esto pero tuvieramos enviando datos a Google Analytics tendríamos que adaptarnos.</p>
<h3><b>¿Cuando entró en vigor?</b></h3>
<p>Está aprobado desde el 2016 y durante este tiempo ha estado en periodo de adaptación. Pasa a ser obligatorio el <b>25 de mayo de 2018</b>.</p>
<h3><b>Cómo cumplir con el RGPD si tienes un ecommerce</b></h3>
<p>Un profesional debería hacer una auditoría de tu tienda/negocio para reflejar que puntos se cumplen o no, tareas a realizar y un calendario de adaptación.</p>
<p>Primeramente vamos a indicar una lista de acciones en la gestión de ecommerce que a partir de ahora quedan invalidadas:</p>
<ul>
<li>Enviar emails a personas que no lo hayan solicitado explícitamente. Prohibido (antes ya lo estaba) comprar listas de terceros o enviar a una lista de otra fuente.</li>
<li>No se pueden enviar emails relacionados con carritos abandonados, compras anteriores, cupones, ofertas, si el usuario no ha aceptado previamente el envio este tipo de emails. Esto es expandible a los SMS.</li>
<li>Si el cliente solicita sus datos personales que nos confió, es ilegal no facilitarselos.</li>
</ul>
<p>En segundo lugar se indican nuevas obligaciones que entran en vigor con la nueva Ley:</p>
<h4><b>Eliminar cuentas de usuarios.</b></h4>
<p>A partir de ahora el usuario debería tener a su disposición una sección donde podrá “<b>Eliminar cuenta</b>” o similar para cumplir con el <em>Derecho al Olvido</em>. Esta funcionalidad eliminaría la cuenta y los datos personales que tengamos sobre este usuario, menos los datos de carácter fiscal.</p>
<p>Esto es extensible a terceros, es decir, tienes que informar a esos proveedores de servicios, que en su día enviaste esa información,  para que lo eliminen.</p>
<p>Este borrado de datos afecta también a las copias de seguridad. Plantéate esta nueva situación a tu webmaster/hosting para que aplique la mejor solución.</p>
<h4><b>Edición de datos </b></h4>
<p>Para cumplir con el <strong>derecho de rectificación</strong> es necesario que los usuarios puedan rectificar los datos recabados. Esto se amplía a datos recopilados por otras fuentes como Facebook, Google, Amazon, etc. con la opción “Inicio de Sesión con Facebook, Amazon, Google,&#8230;” Esa es la parte compleja técnicamente ya que la edición de datos desde la cuenta de cliente registrado (no invitado) viende por defecto en la mayoria de CMS permiten.</p>
<h4><b>Exportación de datos del usuario</b></h4>
<p>Igual que con el borrado o la edición de datos, el usuario deberá poseer la opción de exportar sus datos para cumplir con el <em>derecho de portabilidad</em>. El cliente podrá descargarlos y visualizarlos desde su cuenta de usuario.</p>
<h4><b>Consulta de datos de usuario</b></h4>
<p>El usuario podrá consultar en cualquier momento qué datos suyos están siendo tratado por parte de una tienda online en cualquier momento. Además del origen de esos datos, la finalidad del tratamiento, si va a ser comunicado en el futuro, si se ha enviado sus datos a un tercero o fecha/hora en que acepto los Términos y condiciones y Política de privacidad.</p>
<p>En el caso de compras como invitados también hay que darles una opción para esta consulta aunque no tenga cuenta de cliente creada:</p>
<ul>
<li>Mediante un contacto directo con el responsable del fichero para que le proporcione esta información.</li>
<li>Mediante un sistema que al introducir un email u otro identificador se muestre los resultados asociados a esa información, al menos, de manera temporal.</li>
</ul>
<h4><b>Restringir el procesamiento de datos</b></h4>
<p>Similar al apartado de eliminación de cuenta, con esta implementación, el RGPD busca una desactivación temporal de su cuenta hasta que el usuario decida activarla de nuevo.</p>
<h4><b>Ley de Cookies</b></h4>
<p>Con la aplicación de este nuevo reglamento, al igual que con la anterior LOPD, el consentimiento no puede ser explicitado y tiene que ser aceptado para aplicar las cookies.</p>
<p><strong>Las cookies deben cargarse en el equipo del usuario después (no antes) de que éste otorgue su consentimiento</strong>. Pero esto no es nuevo, sólo que nadie lo cumple a rajatabla.</p>
<h4>Verificación de la edad del usuario</h4>
<p>En caso de menor de 16 años, el sistema no debería permitir el registro o la compra, a menos que sus padres o tutor de autorización. Si se introduce un nuevo campo fecha en el formulario podremos validarlo y llevar a cabo con la acción o  mostrar un aviso de error. Y en caso de falseo de datos, el propietario estará exento de responsabilidad.</p>
<p><b>Caducidad de los datos</b></p>
<p>Si los datos provenientes de nuestros usuarios han dejado de tener validez, han caducado o su fin ya no tiene sentido no debemos seguir conservando esa información. Los datos fiscales de pedidos/facturas/albaranes/devoluciones deberemos mantenerlos 4 años para cualquier consulta o inspección fiscal.</p>
<h3><b>Pasos para adaptarse al nuevo reglamento</b></h3>
<p>Los siguientes consejos hacen referencia a la parte técnica, formularios e email marketing. Como cada empresa tiene sus particularidades, debería buscar más información o consultar con un experto en este tema para cumplir con la ley al 100% y no dejar cabos sueltos o, al menos, ser consciente de ese cabo suelto.</p>
<p>Indicar que muchas de estas premisas ya las exigía la LOPD por lo que, si estabas ya al día en el cumplimento de la ley, tendrás menos trabajo para la adaptación.</p>
<h4><b>Adaptar los formularios eliminado todos los checkboxs marcados automáticamente</b></h4>
<p>En todos los formularios presentes en la tienda, registro, newsletter, proceso de compra, comentario de producto, etc. deberemos tener una casilla de consentimiento que el cliente deberá hacer click obligatoriamente para que el formulario sea enviado. No sirve el típico . “Al enviar este formulario acepta nuestra política de privacidad”. Eso pasó a la historia hace tiempo.</p>
<p>Conjuntamente se añadirá una capa de información con los principales aspectos del tratamiento de datos:  Responsable, Finalidad, Legitimación, Destinatarios, Derechos y Información adicional. En esta primera capa se mostrará un enlace a una segunda capa, página de política de privacidad, donde el usuario podrá ampliar la información. En otro post sobre RGPD se informaba de ello.</p>
<h4><b>Eliminar todas las suscripciones automáticas</b></h4>
<p>Si un cliente realiza un pedido, no sele debe enviar emails no transaccionales si no lo ha marcado explícitamente. O si ha realizado un pago como invitado está prohibido guardarlo como cliente registrado.</p>
<h4><b>Adecuar/actualizar la política de privacidad<br />
</b></h4>
<p>Debemos indicar que cumplimos y nos sometemos al RgPD.</p>
<p>Debes especificar qué información recogemos de los usuarios (por ejemplo, sus direcciones IP, desde qué tipo de dispositivo navegan, cookies, duración de la visita y páginas visitadas, su email, teléfono, nombre, dirección de envío y dirección de facturación, etc.)</p>
<p>Especificar quién, además de usted, tiene acceso a la información que guardas de tus usuarios (como por ejemplo Google, Mailchimp, Disqus…) Todos ellos son destinatarios de la información de tus usuarios y deben quedar consignados en tu Política de Privacidad.</p>
<p>Especificar la identidad del responsable de la gestión de los datos personales (puede ser un delegado en tu nombre).</p>
<p>Especificar que los usuarios tienen derecho a solicitar al responsable el acceso a los datos personales que hayan facilitado, a su rectificación o supresión, a la limitación de su tratamiento o a oponerse al tratamiento, así como el derecho a la portabilidad de los datos.</p>
<p>Especificar la finalidad que vas a dar a los datos recogidos, y durante qué plazo vas a guardarlos.</p>
<p>Por último, si hay procesos automatizados como por ejemplo meter a un usuario en un segmento u otro de tu lista según qué acciones hayan realizado, esto debe estar explicado, siempre que vaya a tener consecuencias jurídicas para el afectado (si tienes dudas sobre esto, ya sabes, consulta con un experto).</p>
]]></content:encoded>
							<wfw:commentRss>https://www.dinaweb.net/rgpd-magento/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
							</item>
		<item>
		<title>Qué es y cómo afecta el RGPD</title>
		<link>https://www.dinaweb.net/que-es-y-como-afecta-el-rgpd/</link>
				<comments>https://www.dinaweb.net/que-es-y-como-afecta-el-rgpd/#respond</comments>
				<pubDate>Mon, 30 Apr 2018 19:06:03 +0000</pubDate>
		<dc:creator><![CDATA[Federico Chulilla]]></dc:creator>
				<category><![CDATA[Seguridad]]></category>

		<guid isPermaLink="false">http://www.dinaweb.net/?p=1983</guid>
				<description><![CDATA[¿Qué es el RGPD? El GDPR (General Data Protection Regulation), RGPD (Reglamento General de Protección de Datos de la UE) O LGDP (Ley general de protección de datos) son un conjunto de regulaciones creadas para regular la gestión y el tráfico de datos en el marco de la Unión Europea. ¿Cuándo entra en vigor? El... <a class="more-link" href="https://www.dinaweb.net/que-es-y-como-afecta-el-rgpd/">Continuar leyendo <span class="meta-nav">→</span></a>]]></description>
								<content:encoded><![CDATA[<h2><b>¿Qué es el RGPD?</b></h2>
<p>El <b>GDPR</b> (General Data Protection Regulation), <b>RGPD</b> (Reglamento General de Protección de Datos de la UE) O <b>LGDP</b> (Ley general de protección de datos) son un conjunto de regulaciones creadas para regular la gestión y el tráfico de datos en el marco de la Unión Europea.</p>
<h3><b>¿Cuándo entra en vigor?</b></h3>
<p>El nuevo reglamento ha entrado en vigor el 25 de mayo de 2016, pero no será hasta el 25 de mayo de 2018 cuando tenga que aplicarse de forma obligatoria.</p>
<h3><b>¿Y por qué es un hito con respecto a otros reglamentos o directivas anteriores?</b></h3>
<p>Porque unifica las normas de protección de datos a nivel europeo, consolide los derechos de los usuarios de toda Europa y establece nuevas obligaciones para todas las organizaciones/empresas que ofrecen bienes y servicios en Europa.</p>
<p>La aplicación de esta nueva normativa RGPD afecta a <strong>empresas europeas y a empresas internacionales</strong> que trabajen con datos de usuarios residentes en la UE.</p>
<p>Así mismo, mientras que la anterior Directiva 95/46/CE que regulaba la protección de datos en los estados miembros dejaba margen de actuación a a cada país miembro, <b>el nuevo Reglamento es de aplicación directa (pasa a ser normativa interna desde el momento en que entra en vigor)</b>, sin que sea necesario ningún trámite previo de adaptación.</p>
<h4><b>La nueva normativa de la UE no deroga la LOPD (actual)</b></h4>
<p>El Reglamento de la UE no deroga automáticamente la LOPD, simplemente anula las medidas que resulten incompatibles. Siempre y cuando no existan medidas incompatibles ambas normativas podrán convivir en el futuro.</p>
<h3><b>¿Cómo nos afecta como usuarios?</b></h3>
<ol>
<li>Tu consentimiento para proporcionar tu información debe ser explícito.Ahora hay que dar un consentimiento ( no se admite el consentimiento tácito como con la LOPD) a las empresas mediante una aprobación muy clara.</li>
<li>Las empresas tienen derecho a recopilar lo estrictamente necesario. Por cada Newsletter o promoción por SMS, las empresas sólo necesitan tu email o tu número (que tú habrás aceptado enviarles).</li>
<li>Puedes pedir que se transfieran todos tu datos. Se permitirá al ciudadano solicitar la transferencia de datos de un proveedor de servicios de Internet a otro.  (y que el antiguo la borre definitivamente)</li>
<li>Puedes solicitar que tus datos sean borrados en cualquier momento. LLamado <b>derecho al olvido</b>, se puede revocar el tratamiento de datos en cualquier momento, pudiendo exigir la supresión y eliminación de los datos en redes sociales o buscadores de internet.</li>
<li>15 años: la edad legal para inscribirse en redes sociales sin autorización de los padres. 15 años será la edad mínima para que los menores puedan consentir por sí solos el tratamiento de sus datos personales online</li>
<li>Posibilidad de acción colectiva frente a la justicia. Si sientes que se ha violado alguno de los derechos relativos de la protección de tus datos personales puedes llevar a cabo una acción judicial colectiva (“class action”)</li>
<li>Sanciones a las empresas. Para las empresas que no cumplen con la normativa, el riesgo de hacer frente a una sesión es alto, hasta 20 millones de euros o un 4% de su facturación mundial anual.</li>
<li>El responsable del fichero puede exigir un <b>canon</b>  por los costes administrativos de atender la petición.</li>
</ol>
<h3><b>Soy una empresa, ¿cómo me afecta la llegada de la RGPD?</b></h3>
<ol>
<li>Responsabilidad proactiva. Las empresas deben realizar un análisis de los procesos de tratamiento de datos.</li>
<li>Valoración adecuada de los riesgos. Necesidad de una evaluación de impacto de los los posibles daños y la probabilidad que tienen de producirse especialmente cuando se tratan de datos que tienen que ver con política, orientación sexual o salud.</li>
<li>Identificar un responsable. Persona que toma las decisiones sobre la finalidad y destino de los datos</li>
<li>Especificar la finalidad. Hay que conseguir el consentimiento para cada fin de los datos e informar en el caso de elaboración de los perfiles.</li>
<li>Declarar la legitimación. La base legal del tratamiento de datos ha de ser la adecuada.</li>
<li>Destinatarios. Si se van a ceder los datos a terceros, el usuario deberá ser informado.</li>
<li>Derechos de accesos, rectificación, supresión portabilidad de sus datos</li>
<li>Muy recomendable que las organizaciones cuenten con un <b>delegado de protección interno o externo</b> (DPO) que asista a las organizaciones en el proceso de cumplimiento normativo.</li>
</ol>
]]></content:encoded>
							<wfw:commentRss>https://www.dinaweb.net/que-es-y-como-afecta-el-rgpd/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
							</item>
		<item>
		<title>Cambiar la URL del admin</title>
		<link>https://www.dinaweb.net/cambiar-url-admin-magento/</link>
				<comments>https://www.dinaweb.net/cambiar-url-admin-magento/#respond</comments>
				<pubDate>Fri, 29 Dec 2017 09:43:01 +0000</pubDate>
		<dc:creator><![CDATA[Federico Chulilla]]></dc:creator>
				<category><![CDATA[Seguridad]]></category>

		<guid isPermaLink="false">http://www.dinaweb.net/?p=1957</guid>
				<description><![CDATA[¿Por que es recomendable modificar la ruta del backend? Para proteger nuestro backend de hackers, ataques de fuerza bruta y cotillas indeseados es muy recomendable cambiar la url de acceso del admin. Esto es debido a que Magento y otros CMS establecen la URL del administrador a una ruta por defecto. En el caso de... <a class="more-link" href="https://www.dinaweb.net/cambiar-url-admin-magento/">Continuar leyendo <span class="meta-nav">→</span></a>]]></description>
								<content:encoded><![CDATA[<h2>¿Por que es recomendable modificar la ruta del backend?</h2>
<p>Para proteger nuestro backend de hackers, ataques de fuerza bruta y cotillas indeseados es muy recomendable cambiar la url de acceso del admin.</p>
<p>Esto es debido a que Magento y otros CMS establecen la URL del administrador a una <strong>ruta por defecto</strong>.</p>
<p>En el caso de Magento es /admin, por ejemplo http://www.midominio.es/admin/.</p>
<p>Para WordPress sería /wp-admin, por ejemplo http://www.midominio.es/wp-admin/.</p>
<p>Esto que estamos diciendo no es algo top secret y es conocido por todo el mundo. Incluyendo a bots y crackers que intentarán por fuerza bruta hacer miles de intentos hasta lograr con la combinación que les abra las puertas del administrador.</p>
<p>Por este motivo y tras un Shoplift bug reportado en 2015 Magento desarrolló un parche de seguridad ( SUPEE-5344) junto a una serie de buenas prácticas de seguridad para ponérselo un poco más difícil a los intrusos.</p>
<p>Entre esa buenas prácticas, <strong>Magento recomienda usar una url personalizada</strong> para el backoffice en vez de la que él establece por defecto (/admin) en la instalación <strong>y que sea sólo conocida por las personas necesarias</strong>. <strong>Esto reduce la exposición de nuestros datos más valiosos</strong> como clientes, productos, pedidos, tarjetas de crédito y que se pueda tomar el control de la tienda remotamente.</p>
<h2>Como cambiar la URL del admin en Magento 1</h2>
<p>Magento 1 permite este cambio directamente desde la configuración pero se recomienda hacerlo modificando ficheros por su eficacia y generación de menos sudores fríos.</p>
<p>Abrir el archivo local.xml situado dentro del directorio app/etc. Dentro del nodo &lt;admin&gt;</p>
<p>encontrarás la sección:</p>
<p>&lt;frontName&gt;&lt;![CDATA[admin]]&gt;&lt;/frontName&gt;</p>
<p>Deberemos cambiar el argumento ‘admin’ por la ruta que deseemos en minúsculas y sin espacios.</p>
<p>Por ejemplo</p>
<p>&lt;frontName&gt;&lt;![CDATA[mibackend]]&gt;&lt;/frontName&gt;</p>
<p>Guardamos el fichero. Lo subimos al servidor si lo estamos editando fuera de él y borramos la caché de una de las siguientes formas:</p>
<ul>
<li>En el admin, desde Sistema &#8211; Gestor de la cache  y hacemos click en el botón Flush Magento Cache.</li>
<li>Borrando el directorio /var/cache del servidor.</li>
</ul>
<h2>Como cambiar la URL del admin en Magento 2</h2>
<p>No es recomandable cambiarlo directamente desde el archivo de configuracon app/etc/env.php.</p>
<h3>Método Admin</h3>
<ol>
<li>En el admin, vamos a Tiendas -&gt; Configuración -&gt; Avanzado -&gt; Admin y dentro de la sección Admin Base URL section.</li>
<li>En Custom Admin Path le decimos que sí y en Custom Admin Path añadimos el path. Este patch será añadido a la variable Custom Admin URL configurable en la misma sección.</li>
<li>Borramos la caché.</li>
</ol>
<h3>Método SSH</h3>
<p>Conectamos via SSH, vamos al root y ejecutamos el siguiente comando:<br />
php bin/magento setup:config:set &#8211;backend-frontname=»miadmin»<br />
Donde miadmin es la nueva ruta.</p>
]]></content:encoded>
							<wfw:commentRss>https://www.dinaweb.net/cambiar-url-admin-magento/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
							</item>
		<item>
		<title>Cambiar el login de Magento a sensible a mayúsculas</title>
		<link>https://www.dinaweb.net/cambiar-login-magento-sensible-mayusculas/</link>
				<comments>https://www.dinaweb.net/cambiar-login-magento-sensible-mayusculas/#respond</comments>
				<pubDate>Wed, 15 Feb 2017 08:15:27 +0000</pubDate>
		<dc:creator><![CDATA[Federico Chulilla]]></dc:creator>
				<category><![CDATA[Seguridad]]></category>

		<guid isPermaLink="false">http://www.dinaweb.net/?p=1951</guid>
				<description><![CDATA[Magento por defecto permite el login en el backend sin diferenciar entre mayúsculas o minúsculas. Sin embargo, es recomendable cambiar este modo (case sensitive) para mejorar la seguridad del administrador y de toda la información que contiene. Habilitar esta opción pondrá un poco más difícil el hackeo de nuestra cuenta al limitar sus posibilidades. Por... <a class="more-link" href="https://www.dinaweb.net/cambiar-login-magento-sensible-mayusculas/">Continuar leyendo <span class="meta-nav">→</span></a>]]></description>
								<content:encoded><![CDATA[<p>Magento por defecto permite el login en el backend sin diferenciar entre mayúsculas o minúsculas. Sin embargo, es recomendable cambiar este modo (case sensitive) <strong>para mejorar la seguridad del administrador</strong> y de toda la información que contiene. Habilitar esta opción pondrá un poco más difícil el hackeo de nuestra cuenta al limitar sus posibilidades.</p>
<p>Por poner una ejemplo si nuestra contraseña es ‘LaP1)3Iz0’, intentarlo con ‘lap1)3iz0’ no funcionará si el login es sensible a mayúsculas.</p>
<p>Vamos a ver los pasos a seguir para que el login de Magento sea sensible a mayúsculas o minúsculas.</p>
<h2>Magento 1</h2>
<ol>
<li>Acceder al admin.</li>
<li>Ir a Sistema (System).</li>
<li>Seleccionar la opción ‘Configuración’ (Configuration).</li>
<li>Ir a avanzado (Advanced) &gt;&gt; Admin.</li>
<li>Seleccionar la opción Seguridad (Security).</li>
<li>Cambiar &#8216;Sensible mayúsculas&#8217; a  Sí (Login is Case Sensitive’ a Yes) .</li>
<li>Guardar configuración.</li>
</ol>
<h2>Magento 2</h2>
<ol>
<li>Acceder al administrador</li>
<li>Ir a Tiendas (Stores)</li>
<li>Seleccionar la opción ‘Configuración’ (Configuration).</li>
<li>Ir a avanzado (Advanced) &gt;&gt; Admin.</li>
<li>Seleccionar la opción Seguridad (Security).</li>
<li>Cambiar &#8216;Sensible mayúsculas&#8217; a  Sí (Login is Case Sensitive’ a Yes) .</li>
<li>Guardar configuración.</li>
</ol>
]]></content:encoded>
							<wfw:commentRss>https://www.dinaweb.net/cambiar-login-magento-sensible-mayusculas/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
							</item>
		<item>
		<title>Parches de seguridad para Magento, desde SUPEE-1533 a SUPEE-7405</title>
		<link>https://www.dinaweb.net/parches-magento/</link>
				<comments>https://www.dinaweb.net/parches-magento/#comments</comments>
				<pubDate>Mon, 18 May 2015 22:18:30 +0000</pubDate>
		<dc:creator><![CDATA[Federico Chulilla]]></dc:creator>
				<category><![CDATA[Magento]]></category>
		<category><![CDATA[Seguridad]]></category>

		<guid isPermaLink="false">http://www.dinaweb.net/?p=1646</guid>
				<description><![CDATA[Parche SUPEE-7405 Lanzado el 20 de Enero (SUPEE-7405 v1.0). Este parche es un paquete de parches que cierra varios problemas de seguridad que pueden derivar en robo de información de clientes o tomar control de sesiones dentro del administrador. En Febrero se lanzó la segunda versión, SUPEE-7405 v1.1, que soporta PHP 5.3 y resuelve ciertos... <a class="more-link" href="https://www.dinaweb.net/parches-magento/">Continuar leyendo <span class="meta-nav">→</span></a>]]></description>
								<content:encoded><![CDATA[<h2 dir="ltr">Parche SUPEE-7405</h2>
<p>Lanzado el 20 de Enero (SUPEE-7405 v1.0). Este parche es un paquete de parches que cierra varios problemas de seguridad que pueden derivar en robo de información de clientes o tomar control de sesiones dentro del administrador.</p>
<p>En Febrero se lanzó la segunda versión, SUPEE-7405 v1.1, que soporta PHP 5.3 y resuelve ciertos errores de la versión anterior. Si no has instalado la nueva versión deberías instalar previamente la primera si tu versión de Magento es menor a 1.9.2.3.</p>
<p>Magento 1.9.2.3 ya incluye SUPEE-7405 v1.0 y 1.9.2.4 ya incluye SUPEE-7405 v1.1</p>
<h2 dir="ltr">Parche SUPEE-6788</h2>
<p>Notificado en Octubre de 2015. El parche SUPEE-6788 es un subconjunto de parches que resuelve más de 10 problemas de seguridad incluyendo ejecución de código remota y robo de información vulnerable. Aunque no hay noticias de ataques conocidos, Magento alerta de su peligro.</p>
<p>De los parches de seguridad lanzados hasta el momento este es el que más problemas puede darte por lo que es más recomendable todavía testearlo previamente en un entorno de desarrollo.</p>
<p>Esto es debido a que afecta a extensiones y personalización añadidas que hacen gran uso de variables personalizadas y rutas del admin (usan &lt;use&gt;admin&lt;/use&gt;» en vez de  «&lt;custom_module after=»Mage_Adminhtml»&gt;CustomModule_Adminhtml&lt;/custom_module&gt;). Sobre un 80% de  <a href="https://docs.google.com/spreadsheets/d/1LHJL6D6xm3vD349DJsDF88FBI_6PZvx_u3FioC_1-rg/edit?pli=1#gid=0">extensiones</a> han sido detectadas que fallan despues de añadir el parche. Por lo tanto, es necesario <strong>actualizar todas estas extensiones que no funcionen</strong>, eliminar las que no se usen y pedir nuevas versions funionales a los desarrolladores de la extension.</p>
<p>Para que el parche tenga efecto 100% es necesario <strong>deshabilitar el enrutamiento seguro</strong>.  Esto se hace dentro del administrador en Sistema – Configuración – Administrador – Seguridad – Modo compatible con rutas de extensión.</p>
<p>La versión 1.9.2.2 incluye este parche por lo que también puedes realizar una actualización vía Downloader.</p>
<p>Puedes encontrar más info del parche en <a href="http://magento.com/security/patches/supee-6788">http://magento.com/security/patches/supee-6788</a> y <a href="https://magento.com/security/patches/supee-6788-technical-details">https://magento.com/security/patches/supee-6788-technical-details</a></p>
<h2 dir="ltr">Parche SUPEE-6482</h2>
<p>Notificado en Agosto de 2015, este parche es una medida preventiva ya que no se conoce ataque producido al respecto. Este parche de seguridad tapa ciertas vulnerabilidades para Magento Community. Éstas están relacionadas con el API de Magento, la inclusión de código arbitrario en el request y el escalado de privilegios en el caso de obtención de datos. Este problema solo afecta a servidores y configuración de PHP específicos pero es recomendable prevenirla.</p>
<p>También elimina cross-site-scripting al tapar la posibilidad de que los atacantes roben cooies para hacerse pasar por usuarios y engañar a otros hagan click en enlaces maliciosos.</p>
<h2 dir="ltr">Parche SUPEE-6285</h2>
<p dir="ltr">Añadido en Julio de 2015, este paquete da protección contra varios tipos de inseguridades como ataques por inyeccion, identificaciones fraudulentas o cross-site scripting.</p>
<p dir="ltr">Principalmente previene que potenciales atacantes puedan acceder como administrador al último feed con los pedidos recientes, feed que contiene información personal que pueda ser usada fraudullentamente para obtener más información o para posterirores ataques. Tambien tapona una serie de agujeros de seguridad relacionados con cross-site scripting (XSS), cross-site request forgery (CSRF) o permisios ACL para extensiones de terceras partes.</p>
<p>Como decía uno de los principales problemas que soluciona es la inyección de código a través de la plantilla o la obtención de datos sin permiso. Por ello el parche modifica los siguientes archivos de la plantilla base de Magento:</p>
<ul>
<li>app/ design/ frontend/ base/ default/ template/ checkout/ cart.phtml</li>
<li>app/ design/ frontend/ base/ default/ template/ checkout/ cart/ noItems.phtml</li>
<li>app/ design/ frontend/ base/ default/ template/ checkout/ onepage/failure.phtml</li>
<li>app/ design/ frontend/ base/ default/ template/ rss/ order/ details.phtml</li>
<li>app/ design/ frontend/ base/ default/ template/ wishlist/ email/ rss.phtml</li>
<li>app/ design/ frontend/ default/ modern/ template/ checkout/ cart.phtml</li>
</ul>
<p>Después de aplicar el parche, es necesario revisar si algunos de los anteriores archivos está en nuestra plantilla personalizada. De estar, tendremos que comparar y pasar el código que ha modificado el parche a nuestra plantilla para que estemos protegidos.</p>
<p dir="ltr">A la hora de instalar este parches hay que estar seguros que está instalado el anterior, SUPEE-5994.</p>
<p dir="ltr">Notas:  la versión 1.9.2 incluye la última versión del parche por lo que no haría falta instalarlo. Si se ha instalado la primera versión de este parche para la versión 1.9.1.1 habrá que revertir el parche (v1) e instalar la nueva versión (v2).</p>
<h2 dir="ltr">Parche SUPEE-5994</h2>
<p dir="ltr">Magento anunció en Mayo de 2015 un nuevo <strong>parche de seguridad</strong> para prevenir potenciales ataques recomendando su inmediata implementación.</p>
<p dir="ltr">Este parche, denominado SUPEE-5994, realmente es un paquete de 8 subparches que corrige varias funcionalidades del núcleo susceptibles de ser atacables y que han sido descubiertas por el programa de seguridad multi-punto.</p>
<p dir="ltr">¿Que problemas se han descubierto?</p>
<ul>
<li>Los atacantes podrían descubrir la URL de login del panel de admon.</li>
<li>Posibilidad de obtener información de los usuarios a través de sus direcciones guardadas en la tienda.</li>
<li>Posibilidad de obtener información de los usuarios e información de pago nutriéndose de los recurring profiles.</li>
<li>A través de URL de imágenes ficticias se podrían generar excepciones que conllevan a errores internos del servidor.</li>
<li>Ejecución de Javascript a través del Magento Connect Manager que puede derivar en instalaciones de extensiones maliciosas.</li>
<li>Modificación, exportación de datos o ejecución de código remoto al exportar información a través de hojas de cálculo.</li>
<li>Ejecución de Javascript en el contexto de las sesiones de los usuarios para el robo de información.</li>
<li>Posibilidad de instalación de extensiones maliciosas.</li>
</ul>
<p dir="ltr">En resumen, los atacantes pueden <strong>obtener acceso a la información de los clientes de la tienda de forma fraudulenta y ejecutar código malicioso</strong>.</p>
<p dir="ltr">Todas las versiones de Magento Community Edition están afectadas y es posible descargar el parche para las versiones 1.4.1- 1.9.1.1 desde la página oficial de Magento cuyo enlace viene al final del post.</p>
<p dir="ltr">Importante: Este parche debería ser instalado como complementación de los anteriores “shoplift patchs” denominados SUPEE-5344 y SUPEE-1533.</p>
<h2 dir="ltr">Parche SUPEE-5344</h2>
<p dir="ltr">Esta vulnerabilidad sobre la ejecución remota de código (RCE) fue publicada por Check Point® (empresa dedicada a la seguridad en Internet) a finales de enero de 2015. La vulnerabilidad afecta tanto a Magento Enterprise Edition como Magento Community Edition y permite a los atacantes obtener, saltándose los mecanismos de seguridad, el <strong>control sobre una tienda y tener información a datos sensibles</strong>, incluyendo la información personal de los clientes, bases de datos, etc. También puede afectar a los números de tarjeta de crédito en el caso de que estuvieran almacenados en la plataforma, cosa que no suele ser habitual y no se recomienda a priori. Para prevenir estos problemas Magento emitió un parche para este problema el 9 de febrero de 2015 denominado <strong>SUPEE-5344</strong>.</p>
<p dir="ltr">Puedes comprobar la exposición de tu ecommerce usando este <a href="http://magento.com/security-patch">enlace</a>  y añadiendo tu ruta para el admin.</p>
<p dir="ltr">Auditoría manual para saber si mi sitio ha sido asaltado:</p>
<ul>
<li dir="ltr">
<p dir="ltr">Revisar las cuentas de administrador creadas dentro del panel e eliminar las sospechosas.</p>
</li>
<li dir="ltr">
<p dir="ltr">Comprobar si en la instalación de Magento hay archivos recientes desconocidos o sospechosos.</p>
</li>
<li dir="ltr">
<p dir="ltr">Chequear permisos ocultos y permisos de archivo incorrectos.</p>
</li>
</ul>
<p dir="ltr">Si encuentra indicios de que su servidor/plataforma ha sido atacada póngase en contacto con su empresa de hosting.</p>
<p dir="ltr">Nota: Magento ha sacado la nueva version 1.9.1.1 que ya incluye este parche por defecto.</p>
<h3 dir="ltr">Parche SUPEE-1533</h3>
<p dir="ltr">Repara dos potenciales vulneraciones por <strong>ejecucion de codigo remoto</strong>. Disponible desde el 3 de Octubre de 2014. Si el atacante tenía un acceso al administrador, las vulnerabilidades permiten:</p>
<ul>
<li dir="ltr">
<p dir="ltr">Permitir a un atacante ejecutar código en el servidor.</p>
</li>
<li dir="ltr">
<p dir="ltr">Mediante un fichero  .csv  encapsulado se podían modificar los permisos de directorios ( por ejemplo 777).</p>
</li>
</ul>
<p dir="ltr">Afecta a todas las versiones Magento Community Edition (CE) y Enterprise Edition (EE) así como a los sistemas operativos CentOS 5.x and 6.x y RedHat Enterprise Linux 5.x and 6.x</p>
<p dir="ltr">Todo responsable de tienda online basada en Magento o en cualquier CMS Open Source debería añadir los parches, o actualizar a la versión pertinente, que van saliendo así como estar pendiente de las novedades en este aspecto para estar lo más prevenido posible y no “dejar la puerta abierta” a intrusos.</p>
<p dir="ltr">Si usas sistema de cache PHP como APC/XCache/eAccelerator  regenérala después de parchear o reinicia el servidor web.</p>
<p dir="ltr">Puede descargar todos los parches en<a href="https://www.magentocommerce.com/products/downloads/magento/"> https://www.magentocommerce.com/products/downloads/magento/</a></p>
<p dir="ltr">Como instalar un parche en Magento Community<a href="http://devdocs.magento.com/guides/m1x/other/ht_install-patches.html"> http://devdocs.magento.com/guides/m1x/other/ht_install-patches.html</a></p>
<p>Si necesita ayuda para proteger su tienda puedes usar el <a href="https://www.dinaweb.net/contacto-portafolio/">formulario de contacto</a>.</p>
]]></content:encoded>
							<wfw:commentRss>https://www.dinaweb.net/parches-magento/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
							</item>
	</channel>
</rss>

<!--
Performance optimized by W3 Total Cache. Learn more: https://www.w3-edge.com/products/

Almacenamiento en caché de objetos 14/77 objetos que utilizan disk
Page Caching using disk: enhanced 
Lazy Loading (feed)
Minimizado usando disk
Caching de base de datos 3/14 consultas en 0.010 segundos usando disk

Served from: www.dinaweb.net @ 2026-04-14 21:13:11 by W3 Total Cache
-->