Tienda Online / Ecommerce para TPVPlus con SQL Server

tpvplus-12266-4
Estándar

TPVPlus, sin duda, es un gran software para la gestión del punto de venta,  pero si una pyme quiere llegar al siguiente nivel de diversificación de lineas de negocio, muchos emprendedores y gestores piensan inevitablemente en el mundo del ecommerce.

Como expertos en tiendas online hemos desarrollado varias plataformas propias de ecommerce, la última sobre C# que ya tenemos disponible para todos nuestros nuevos clientes interesados en la venta online. En web4x4 usamos SQL Server como motor de base de datos en nuestros servidores web y al igual que otras consultoras con Prestashop o Magento, lo que cobramos es la configuración e inicialización de la tienda online.

Todos nuestros desarrollos son compatibles e integrables con el SQL Server de TPVPlus, dejando a criterio del cliente el grado de integracion que necesita. En algunos casos solo requieren que se actualicen los productos de forma automatica y en otros una integracion mas completa: Clientes, Productos, Facturas, Estadísticas, etc, todo lo que puedas pedir es susceptible de integración, siempre que la base de datos sea legible.

Si quieres mas información para un modulo de integración y vender online desde tu TPVPlus escríbenos a david.moral@web4x4.es o llámanos al 628 81 89 89.

 

*TPVPlus es una marca registrada de Sage SP.

[kb_amz_product_gallery] [kb_amz_product_attributes]
[kb_amz_product_actions]
[kb_amz_product_content replace=”Yes”]
[kb_amz_product_reviews]
[kb_amz_product_similar]

Pros y contras de Access como base de datos

statistics-access-2010 (1)
Estándar

Siempre se habla de la base de datos Access como la hermana pobre de SQL Server, y aunque, para entornos empresariales muy fuertes si recomiendo otro tipo de motor de SQL, en Pymes de menos tamaño o autonomos el uso de Access puede ser recomendable para empezar a gestionar la informacion del negocio a través de una base de datos relacional. Os cuento algunos pros y contras de Access.

Localización de los datos

En primer lugar, todos los datos estarian dentro de un solo archivo, que se mantiene por el propio Access. Esto permite una solución de copia de seguridad simple. También permitiría cargar o descargar las bases de datos de Access sobre la marcha y por ejemplo, combinar dos bases de datos en una sola.

Desarrollo en el propio IDE de Access (VBA)

Access es más que una base de datos. También cuenta con un entorno de programación completa que es fácil de aprender para los no desarrolladores (VBA). Estos programas también serían parte de la base de datos de Access y por lo tanto podría ser utilizado por un usuario local, mientras que si se usa en entorno web, la aplicación web también tiene acceso a los mismos datos.

Access es a menudo parte de proyectos heredados. Podría haber algo más que datos dentro del archivo de Access. También es posible que otras aplicaciones utilicen la misma base de datos para cualquier propósito. Tiene un rendimiento muy bueno, si sabes lo que estás haciendo.

Multiusuario limitado

El mayor inconveniente sería un entorno multi-hilo. Y el desarrollo web, básicamente, es un entorno de múltiples subprocesos. Hay un gran riesgo de bloquear registros ya que si un usuario está actualizando los datos , otros usuarios no pueden acceder a este. En un entorno multiusuario, también hay un mayor riesgo de corrupción de datos. Pero dado que las bases de datos Access tienden a ser razonablemente pequeñas y compactas, no es un gran problema para hacer copias de seguridad periódicas para evitar este tipo de problemas.

Precio

Access en sí mismo es gratuito. Sólo se paga por Access al comprar Office.

Mover la aplicación

Aún más interesante, si el sistema ya tiene la configuración ADO apropiada / o controladores ODBC instalados, y son muy comunes, a continuación, se puede implementar una aplicación que utiliza Acces simplemente copiando el ejecutable a una nueva ubicación.La aplicación puede crear una nueva base de datos sobre la marcha, llenarlo con los datos por defecto y ya está! Es muy fácil de usar, en comparación con otras alternativas.

Bases de Datos empresariales

Usted podría considerar trabajar con SQL Server o MySQL como alternativas, pero requieren una configuración adecuada y deberían estar alojadas en algún servidor, aunque SQL Server se puede utilizar de una manera similar a Access en la version Express. Si piensa un cambio de base de datos, sugiero un cambio a SQL Server, ya que es totalmente compatible con Access.

Trabajo en web

Puede mover el archivo Access a una ubicación central (equipo o servidor), construir una interfaz web (tal vez en la intranet de la empresa) en ASP.NET utilizando un proveedor de datos específico para Access. La conexión con la base de datos sería esencialmente conexión de un usuario Si usted está pensando una solución empresarial tendrá que desarrollar la aplicación de todos modos.

Si el uso incluye cientos de usuarios, es muy probable que se encuentre con una serie de problemas con Access, pero al menos tiene la mitad del problema abordado y sólo necesita cambiar el código del proveedor de datos en ASP.NET para adaptarse a una solucion empresarial como SQL Server.
 
 
Si estas interesado en mantener tus aplicaciones Access o piensas en una migración a SQL Server mira nuestros servicios profesionales desde Web4x4.es
david.moral@web4x4.es – 628 81 89 89
 
 

Evitar ataques SQL Injection en IIS7 con SQL Server

Estándar

En este post hablaremos sobre un tema que interesa a cualquiera que desarrolle o trabaje con bases de datos en una aplicación web, los ataques con inyección SQL.

¿Que es un ataque con inyección SQL (SQL injection)?

En principio los ataques SQL injection son combinaciones de técnicas para conocer datos sobre la configuración de un servidor web y de su base de datos, de forma que, de manera mas o menos directa, se pueda conseguir acceso a la misma, para usarla en beneficio del atacante, bien borrando datos, copiandolos y vendiendolos posteriormente o manipulandolos para conseguir algún objetivo, como puede ser la propagación de un virus desde esa misma página.

Los ataques consisten en la adición de sentencias SQL especiales que, ejecutadas en el servidor, le den al atacante información tecnica sobre la base de datos y posteriormente acceso de algún tipo.

¿Son evitables todos los ataques  SQL Injection?

Un servidor web publico siempre podrá ser accedido por cualquier usuario que acceda a la página o conecte a través de un programa informático, con lo que siempre estará expuesto. Incluso en servidores internos de redes empresariales podemos tener problemas con cualquier usuario, por eso son importantes el uso de todas las técnicas que vamos a ver en este post.

Es probable que nos dejemos alguna ya que vamos a hablar sobre servidores IIS y SQL Server, podeis dejar vuestras aportaciones en los comentarios si teneis alguna para otras bases de datos o servidor web.

¿Cualquier base de datos es susceptible de un ataque SQL Injection?

En principio las mas usadas en aplicaciones web como Mysql, Oracle, SQL Server y Access (increible que todavia se use para webs) son susceptibles de ser atacadas para conseguir el acceso, cada una con sus diferentes sintaxis, pero en general las técnicas son similares.

Técnicas de defensa ante ataques SQL Injection

1. Páginas de error personalizadas

No hay que ponerselo fácil a los atacantes de nuestras webs.

Al principio de un ataque se usan diferentes sentencias para que la página proporcione errores de sintaxis al intentar ejecutarlas y de esa manera conocer que versión de base de datos usa nuestra aplicación, para ser más precisos en las siguientes oleadas. Si queremos ver los errores cuando estamos desarrollando, pero queremos que sean invisibles al resto de usuarios, podemos generar una página de error personalizada que solo muestre los detalles a una determinada IP o si estas logado en un panel de control de la propia web, mientras que el resto de usuarios veran un bonito mensaje creado por ti sin detalles sobre el error.

2. Uso de procedimientos almacenados.

Una de nuestras experiencias contra ataques de inyeccion SQL fue en un cliente que ya tenia la aplicacion web funcionando y nos llamo para realizar un proyecto de SEO. La web tenia distintas funcionalidades, aunque basicamente era un buscador de textos cientificos. Nuestra sorpresa llego cuando al revisar el código en ASP muchas llamadas a la base de datos se realizaban de manera directa haciendo “select ” con parametros querystring (GET) en vez de usar procedimientos almacenados contra SQL Server.

¿Que implica ejecutar selects con parametros?

Los select con parametros son la puerta de entrada a los ataques SQL injection ya que salvo excepciones que ya veremos mas abajo, su uso deja abierta la puerta para que poniendo un simple punto y coma “;” todo lo que venga detras en el querystring sea ejecutado en la base de datos.

/pagina.asp?id=1;update users set name=’codigo javascript con enlace a un virus’

si en el script pagina.asp usamos una select abierta podemos hacer que la base de datos ejecute la sentencia detrás del ; en este caso cambiando el valor de un campo en toda la tabla de usuarios por un codigo javascript que nos lleve a una pagina con virus, que fue lo que ocurrió en este cliente. Todos los que trabajamos con bases de datos usamos nombres muy parecidos en muchas aplicaciones, por comodidad y sencillez de mantenimiento, con lo que determinadas tablas suelen tender a tener el mismo nombre en muchas webs haciendo mas fácil un ataque dirigido en este sentido.

¿Cual es la ventaja de los procedimientos almacenados?

En el caso de los procedimientos los parametros entran por separado y ademas “tipados”, esto significa que si el servidor espera un valor numerico (int) al recibir el “update …” fallará y no se ejecutará. Y en el caso de varchars podria incorporar el texto en un update, pero nunca se ejecutaría directamente minimizando el riesgo.

¿Tiene alguna debilidad un procedimiento almacenado?

Si, en general en el momento que un procedimiento almacenado se hace “dinámico”, es decir, que no ejecuta directamente siempre la misma operación, sino que recibe en un parámetro la sentencia sql y la ejecuta de manera interna. En este caso el problema es el mismo que en las selects abiertas.

Siempre hay que usar procedimientos parametrizados (ejemplo en ASP):

set cmd=Server.CreateObject(“ADODB.Command”)
Set Cmd.ActiveConnection = wConn
Cmd.CommandType = adCmdStoredProc
Set rs= Server.CreateObject(“ADODB.Recordset”)
Cmd.CommandText = “PROCEDIMIENTO_ALMACENADO”
Cmd.Parameters(“@ID”) = request.QueryString(“id”)
set RS=Cmd.Execute()

3. Filtros en la configuración de la web.

En el caso de IIS7 podemos generar un filtro bastante efectivo en toda la página web haciendo uso del archivo web.config, colocando unas cuantas lineas que protejan los parametros hacia ASP y ASP.NET.

Debajo de <system.webServer> colocaremos este código que dejamos, esto filtra en las URL todas las palabras clave listadas, que , salvo excepciones, son usadas solo en entornos de base de datos. Si el servidor IIS encuentra una coincidencia, muestra el error 404 de no encontrado cuando el atacante intente acceder a la página con esos parametros o URL.

<security>
<requestFiltering>
<filteringRules>
<filteringRule name=”SQLInjection2″ scanQueryString=”true”>
<appliesTo>
<add fileExtension=”.asp” />
<add fileExtension=”.aspx” />
</appliesTo>
<denyStrings>
<add string=”–” />
<add string=”/*” />
<add string=”alter” />
<add string=”begin” />
<add string=”create” />
<add string=”cursor” />
<add string=”delete” />
<add string=”drop” />
<add string=”fetch” />
<add string=”insert” />
<add string=”kill” />
<add string=”open” />
<add string=”select” />
<add string=”sys” />
<add string=”table” />
<add string=”union” />
<add string=”update” />
<add string=”top” />
<add string=”iif” />
<add string=”from” />
<add string=” or ” />
<add string=” in ” />
<add string=”chr” />
<add string=”asc(” />
<add string=”curdir” />
<add string=”len(” />
<add string=”ascii” />
<add string=”substring” />
<add string=”length” />
<add string=”@version” />
<add string=”exists” />
</denyStrings>
</filteringRule>
</filteringRules>
</requestFiltering>
</security>

el problema es que puede haber excepciones en las que haya palabras clave que podamos usar en alguna URL, lo que haria que tuviesemos que quitarlas de este filtro inicial.

4. Función de limpieza

Puede no ser técnicamente muy acertada, pero sin duda es muy efectiva, ya que nos permite dejar pasar en primera instancia determinadas palabras y luego filtrarlas en parametros según nuestra conveniencia, en ASP seria tal que así:
function clear_param(texto)

dim texto_final
texto_final=replace(texto, “SELECT”, “”)
texto_final=replace(texto_final, “‘”, “”)
texto_final=replace(texto_final, “UPDATE”, “”)
texto_final=replace(texto_final, “DELETE”, “”)
texto_final=replace(texto_final, “DROP”, “”)
texto_final=replace(texto_final, “UNION “, “”)
texto_final=replace(texto_final, “%”, “&#37;”)
texto_final=replace(texto_final, “%00”, “”)
texto_final=replace(texto_final, ” TOP “, “”)
texto_final=replace(texto_final, ” GROUP “, “”)
texto_final=replace(texto_final, “=”, “”)
‘texto_final=replace(texto_final, “>”, “&#62;”)
‘texto_final=replace(texto_final, “<“, “&#60;”)
texto_final=replace(texto_final, “IIF”, “”)
texto_final=replace(texto_final, “FROM”, “”)
texto_final=replace(texto_final, ” OR “, “”)
texto_final=replace(texto_final, ” AND “, “”)
texto_final=replace(texto_final, ” IN “, “”)
texto_final=replace(texto_final, ” CHR “, “”)
texto_final=replace(texto_final, ” ASC(“, “”)
texto_final=replace(texto_final, ” CurDir “, “”)
texto_final=replace(texto_final, “LEN(“, “”)
texto_final=replace(texto_final, “SHELL”, “”)
texto_final=replace(texto_final, “ASCII”, “”)
texto_final=replace(texto_final, “SUBSTRING”, “”)
texto_final=replace(texto_final, “LENGTH”, “”)
texto_final=replace(texto_final, “version”, “”)
texto_final=replace(texto_final, “exists”, “”)
clear_param=texto_final

End function

una función de este tipo servirá para limpiar un querystring en el caso de que por alguna razón debamos usarlo directamente sobre una select, para complementar el filtro en web.config:

clear_param(request.QueryString(“id”))

5. Bloqueo de IP´s

Como medio de disuasión es interesante si el atacante no es demasiado habil ya que burlar un bloque de Ip es relativamente sencillo con programas para navegación anónima, pero tambien sirve como bandera del ” te hemos visto y estamos preparados” lo que puede hacer que ese hacker se interese por otras webs más faciles que la nuestra. En la página de errores personalizados podemos tener una función que guarde un log con el error y la IP que lo ha producido, si además guardamos los parametros querystring que han producido el fallo podemos identificar los intentos de hacking a la web y la IP del atacante.

Todas estas técnicas de prevención de ataques SQL injection son aplicables en otros lenguajes, servidores web y bases de datos, usando en cada caso su propia sintaxis.

Si te ha servido este post o se nos olvida algo, por favor, deja un comentario y cuéntanos tu experiencia.

ADODB.Command error ‘800a0cc1’ Item cannot be found in the collection corresponding to the requested name or ordinal.

Estándar

Este error puede significar varias cosas dependiendo de la base de datos.

Por un lado lo mas normal es que estemos llamando a un objeto Cmd.CommandType = adCmdStoredProc  (procedimiento almacenado)  y uno de los parametros que estamos llamando no exista en ese procediminento.

Debemos revisar las lineas:

Cmd.Parameters(“@parametro”)  y revisar que la variable que esta entre las comillas es la misma que tenemos en el procedimiento y que el tipo de dato que le estamos enviando coincide con la declaracion en el procedimiento almacenado.

Esto es valido en general para cualquier version de SQL Server, pero … ¿y si el parametro esta bien?

Muchas veces en nuestras aplicaciones nos encontramos con errores de ADODB.Command error que en los casos normales son mostrados por el navegador para poder revisarlos y solucionarlos. Sin embargo este error en particular nos puede llevar a confusion ya que en primera instancia nos dice que estamos llamando a un campo o parametro que no existe “Item cannot be found in the collection corresponding to the requested name  or ordinal.”

Esto en la mayoria de ocasiones es cierto pero… ¿y si tienes todo bien y el procedimiento almacenado funciona en el sql server?. Bien pues resulta que este error en algunas ocasiones camufla otro distinto en SQL Server 2005 Express y no es hasta que quitamos un Cmd.Parameters cuando nos muestra su verdadera cara:

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e09’

[Microsoft][SQL Native Client][SQL Server]The EXECUTE permission was denied on the object ‘PROCEDIMIENTO’, database ‘VENTAS’, schema ‘dbo’.

Resulta que como es un procedimiento almacenado nuevo y tenemos bien configurada la seguridad, el usuario que abre la conexion no tiene permisos de ejecucion,  no puede leer la declaracion del procedimiento y muestra el error ‘800a0cc1’, aunque ese no sea el error real.

Sin embargo por la situacion anterior podemos perder un buen rato verificando nuestros procedimientos pensando que estan mal.

Moraleja: ADODB.Command error ‘800a0cc1’  Item cannot be found in the collection corresponding to the requested name  or ordinal …. revisa los permisos de ejecucion si tienes SQL Server Express 2005, sino revisa los parametros.

Si te ha servido deja un comentario.