El acceso de CouchDB como servicio de descanso parece inseguro. Cualquiera puede golpear la base de datos y eliminar/agregar documentos una vez que esté expuesta.Cómo proteger CouchDB
¿Qué estrategias existen para proteger el CouchDB?
¿Has leído la documentación de CouchDB http://couchdb.apache.org/docs/overview.html? Tiene una sección de "Seguridad y Validación" que aborda algunas de sus preocupaciones.
Sí, he leído el párrafo. Habla sobre Reader Lists, y dice que hay un modelo de seguridad, estoy buscando detalles como un how-to, ejemplos, una API para agregar a la lista de lectores, etc. – steveolyo
Te tengo, parece que ya has hecho un poco de investigación . No estoy seguro si esto ayudaría: http://books.couchdb.org/relax/reference/security, eche un vistazo si no lo ha hecho. –
Eso tiene buena información, todavía necesita trabajo. Me doy cuenta de que couchdb todavía está en su infancia. Quizás las listas de lectura aún no se hayan implementado. – steveolyo
Lo único que realmente funciona actualmente con respecto a la seguridad es algo así en su configuración de CouchDB.
[couch_httpd_auth]
require_valid_user=true
[admins]
admin = sekrit
Esto pone de autenticación básica HTTP en todos CouchDB. Incluso esto no está bien soportado en las bibliotecas de los clientes. Para python, p. necesitas a patched library.
El segundo enfoque es poner un proxy frente a CouchDB y dejar que el proxy realice el trabajo de autenticación y autorización. Debido al diseño RESTful de CouchDB, esto es bastante fácil.
Todos los demás enfoques deben considerarse hasta ahora altamente experimentales.
Poner un proxy en frente de Couch es una gran idea, pero agrega un poco de sobrecarga. Tengo apache como proxy actualmente. Creo que voy a reformular el pregunta como una nueva aquí en stackoverflow – steveolyo
Esto puede ser un poco diferente de su pregunta original. Si su couchdb es solo una tienda de back-end para una aplicación de servidor completa, puede crear una cuenta especial para que la use y requiera esas credenciales para acceder a couchdb.
Por otro lado, una aplicación de sofá puro que la gente acierta directamente a través de un cliente de JavaScript necesita mucho cuidado para estar seguro.
El uso de reescrituras no es opcional. Necesita una configuración de vhosts que fuerce las solicitudes a su dominio a través de sus reescrituras.
Vuelva a escribir las rutas */_ all_docs y/*/_ design/* en una página 404. De lo contrario, los usuarios pueden enumerar todos los documentos o obtener toda su aplicación.
Reescriba el acceso a un objeto genérico, es decir,/dbname /: id a un programa que puede denegar el acceso si el usuario no puede ver el documento. Lamentablemente, no existe una solución equivalente para el control de acceso basado en documentos de archivos adjuntos.
Utilizamos haproxy para filtrar solicitudes GET en _users. No hay una razón legítima para que alguien de afuera obtenga un registro de usuario o una lista de todos sus usuarios. Queremos que los usuarios puedan registrarse, así que necesitamos acceso de escritura. Actualmente, couch no puede bloquear el acceso de lectura a un archivo db y simultáneamente permite escribir. Es un error. Filtrar con algo como haproxy es nuestra mejor solución por el momento.
Use su propia base de datos para mantener la información de contacto que se suma a la proporcionada por _users. Esto permite un mayor control sobre el acceso.
validate_doc_update debe rechazar cuidadosamente las escrituras que no deberían permitirse.
En todos los casos, necesita imaginar lo que alguien que entendió el sistema podría hacer para subvertirlo y bloquear esas vías de ataque.
Mucho ha cambiado desde 2009, así que voy a arrojar una respuesta aquí. Esta respuesta se extrae del this page on the wiki.
CouchDB tiene una base de datos _users que sirve para la definición de usuarios.Aquí está la esencia directamente de la wiki:
Luego, para cualquier base de datos dada, puede definir permisos por nombre o por rol. La forma en que se implementa la autenticación es a través de una base de datos _session. El envío de un nombre de usuario y una contraseña válidos a la base de datos _session devuelve una cookie de autenticación. Esta es una de las varias opciones para la Autenticación CouchDB. Hay algunas opciones más:
También, dependiendo de qué servicio de alojamiento puede que esté utilizando, tendrá la opción de restringir el acceso al sofá sobre SSL.
Entre Node, Couch y una variedad de otras tecnologías que efectivamente se escalan horizontalmente (agregando más servidores) hay un tipo interesante de presión o incentivo que se pone a los desarrolladores para hacer aplicaciones que escalan bien de esa manera. Pero eso es un problema aparte, todos juntos.
A partir de febrero de 2013 (y CouchDB 1.2), el modelo de seguridad de CouchDB no parece ser lo suficientemente flexible para mí. Aunque seguir así no sería malo y podría ahorrarle mucho tiempo si no se preocupa demasiado por la seguridad, eso no es aplicable si va a producir para usuarios del mundo real.
En este último caso, debe ir con un middleware de autenticación independiente. Esto da la posibilidad de implementar una autenticación personalizada relativamente fácil. Ya sea OAuth, Cookies o SSL, tendrá control total sobre él y la autenticación frente a los servicios de terceros (o sus propios mecanismos de propiedad) parece relativamente sencillo. Hablando de seguridad, también me interesarían los ataques DoS y parece que no podrás restringir la cantidad de solicitudes a CouchDB por medio de CouchDB.
También necesitará su propio nivel porque no existe un soporte claro para la autorización por documento (consulte this para obtener más información). El ejemplo perfecto es mantener una aplicación móvil con muchos usuarios que no comparten datos entre ellos. TouchDB es perfecto para esto, pero probablemente no creará una base de datos separada para cada usuario en el backend con CouchDB, porque no es perfectamente escalable. Con un middleware por separado, puede buscar un campo especial en un documento que identifique al usuario al que pertenece este documento, o emplear cualquier otro tipo de ACL que desee.
No pensaría en ningún problema de rendimiento en una aplicación del mundo real antes de que los problemas de seguridad no se resuelvan. Por lo tanto, incluso la implementación de nginx para reescribir las URL es mucho mejor que la implementación de CouchDB sin cerca en un servidor público. Y además, el rendimiento alcanzado con nginx será insignificante.
Gracias por esta información. ¿Podría apuntarnos a una publicación de blog o artículo que describiría este medio ware se acerca un poco más en profundidad? Realmente ayudaría a mucha gente luchar en este tema. – psp
CouchDB hace galletas, SSL, oauth y multi-usuarios bien:
Aquí hay algo de código real en Python:
from couchdb import Server
s = Server("https://user:[email protected]:6984")
Solicitud de la cookie: URL codificada por encima y por debajo, por supuesto
tienes que poner las credenciales dos veces para empezar con la primera galleta Tanto en el constructor del servidor(), así como el cuerpo de POST _SESSION
code, message, obj = s.resource.post('_session',headers={'Content-Type' : 'application/x-www-form-urlencoded'}, body="name=user&password=password")
assert(code == 200)
Ahora que han recibido una cookie, extraerlo
cookie = message["Set-Cookie"].split(";", 1)[0].strip()
Ahora, pitón de salida y reiniciar
A continuación, solicitar un objeto de servidor, pero sin el nombre de usuario y contraseña en esta ocasión
s = Server("https://example.com:6984")
s.resource.headers["Cookie"] = cookie
Sí, sin contraseña, intente acceder a la base de datos:
db = s["database"]
Opcionalmente configure la opción de cookie "persistente" en el servidor para que la cookie dure más tiempo.
¿Algún problema con este problema? estoy seguro de que ha cambiado mucho en 2 años ... –