Lectura03 en Es

IEEE Systems Journal, vol. 7, NO.
3, septiembre2013489
Aplicaciones de Seguridad de la Teoría lenguaje

formal
Len Sassaman, Meredith L. Patterson, Sergey Bratus, y Michael E. Locasto
Estado belga (política Científica de Bélgica).
L. Sassaman estaba con Universidad Católica de Lovaina, Lovaina autobús
5005 3000, Bélgica.
M. L. Patterson es con Red Lambda, Longwood, FL 32779 EE.UU. (e-mail:
mlp@upstandinghackers.com).
Abstracto-Nosotros presentan un enfoque de la teoría del S. Bratus es con el Dartmouth College, Hanover, NH 03755 EE.UU. (e-mail:
lenguaje formal para mejorar los aspectos de seguridad del sergey@cs.dartmouth.edu).
diseño del protocolo y mensaje-interacciones basadas en sistemas M. E. Locasto es con la Universidad de Calgary, Calgary, AB T2N 1N4,
compuestos complejos. Se argumenta que estos aspectos son Canadá (e-mail: locasto@ucalgary.ca).
Identificador de Objetos Digitales 10.1109 / JSYST.2012.2222000
responsables de una gran parte de la inseguridad sistemas
informáticos modernos. Mostramos cómo nuestro enfoque
conduce a los avances en la validación de entrada, el modelado de
la seguridad, la reducción de la superficie de ataque, y en última
instancia, el diseño de software y la metodología de
programación. Citamos ejemplos basados en las fallas de
seguridad en el mundo real en los protocolos comunes, que
representan diferentes clases de complejidad protocolo. También
se introduce una formalización de una técnica de desarrollo de
explotar, el ataque diferencial árbol de análisis, posible gracias a
nuestra concepción del papel de las gramáticas formales en
materia de seguridad. También se analiza el impacto negativo
innecesariamente mayor complejidad protocolo tiene en la
seguridad. En este trabajo se proporciona una base para el
diseño de los componentes críticos de implementación
verificables con mucho menos carga para los desarrolladores que
es ofrecido por el estado actual de la técnica. Además, ofrece una
base fértil para la exploración adicional en las áreas de análisis
ofensiva y, herramientas de defensa a la inversa, automatizados y
técnicas.
Términos del Índice-Language de teoría de la seguridad, la
composición segura, el diseño del protocolo seguro.
I. Introducción
La composición es los medios de ingeniería primarios de la
construcción del sistema complejo. No importa lo que otros
enfoques de ingeniería o patrones de diseño AP- se aplica, la
realidad económica es que un sistema informático complejo
en última instancia, será tirado gether a- partir de
componentes fabricados por diferentes personas y grupos de
personas. Las interacciones entre estos componentes implican
la creación de los límites de los componentes de
comunicación y marcar el comienzo de los protocolos de
mensajería. Estos límites y protocolos se convierten entonces
en las áreas de ataque, dominando el panorama actual de la
inseguridad de Internet.
Para la división tradicional de un sistema en el hardware,
firmware y software y de software en los controladores de
dispositivos, núcleo del sistema operativo genérico y sus sub-
capas, y varias pilas de software de aplicaciones y bibliotecas,
el hecho de esta composición es tan obvio que comúnmente se
desestimó tan trivial. ¿Cómo más se puede construir
computadoras modernas y software moderno, si no de una
manera modular? Por otra parte, la modularidad se supone que
es bueno
Manuscrito recibió 9 de octubre de del 2011; revisado 17 de de abril de,
2012; aceptado 22 de septiembre de 2012. Fecha de la versión actual 3 de
julio de 2013. La obra de L. Sassaman fue apoyado en parte por la
Universidad Católica de Lovaina Consejo de Investigación: GOA TIEMPO
bajo la subvención GOA / 11/007, y por el IAP Programa P6 / 26 bcrypt del
composición basada en mensajería segura, y el gráfico de
diseño básico principios para reducir estos desafíos. En
particular, se muestra que los retos difíciles de entrada segura
manipulación y asegurar comu- nicación surgen debido a la
para la seguridad y la fiabilidad ya que sin ellos subyacente teoría duro o problemas (es decir, undecidable)
programación se intratable. capaces unsolv- que ciertos diseños de protocolo y los
Sin embargo, los componentes de la composición que se programadores de las implementaciones de la fuerza para
comunican de forma segura ha emergido como el principal resolver para asegurarlos. Postulamos que el (involuntario)
desafío para asegurar la construcción del sistema. introducción de este tipo de problemas en la etapa de diseño
profesionales de la seguridad saben que los límites de del protocolo explica la propensión extrema de ciertos
comunicación se convierten en blancos de ataque de protocolos y formatos de mensaje para producir un flujo
elección, y que las capacidades vulnerables son a menudo aparen- vez más sin fin de vulnerabilidades 0-día a pesar de
causados por interacciones inesperadas entre los los esfuerzos para detener que,
componentes. Sin embargo, las razones de esto son difíciles Nosotros También trazar formas de evitar diseños que son
de alcanzar. Los atacantes desean naturalmente ejecución propensos a convertirse en pesadillas de seguridad para
fiable de sus hazañas, que les lleva a atacar las fronteras de futuros protocolos de Internet. Empíricamente, los intentos de
comunicación como las partes descritas mejor- de resolver un problema de ingeniería que implica una lo
componentes, con el estado tratable. Sin embargo, esto no suficientemente bueno (o 80% / 20%) solución al problema
explica por nuestra incapacidad colectiva para diseñar acostado teoría undecidable sub están condenados a la
sistemas sin interacciones no deseadas. frustración y el fracaso, que se manifiesta de muchas maneras
En este trabajo, se argumenta que a fin de hacerlo bien tales como ninguna cantidad de pruebas para sufficing
seguridad- sabia, necesitamos una nueva comprensión más deshacerse de los insectos, o la complejidad abrumadora y no
fuerte computacional de la teoría de las interacciones del todo correcto funcionamiento de las herramientas de
basadas en mensajes entre los componentes. Utilizamos automatización o de detección creado para hacer frente al
argumentos formales lenguaje complejidad para explicar por problema. Por lo tanto, para evitar estos problemas en el
qué ciertos protocolo y formato de los mensajes decisiones primer lugar (en la etapa de diseño) ahorra mala inversión de
de diseño son conocidos empíricamente que fuentes de la esfuerzo de programación y los costes operativos.
vulnerabilidad, y por qué no parecen los componentes de Observamos que muchos sistemas prácticos no fueron ni no
software respectivos para dar a los esfuerzos de la industria diseñados desarrollados pensando en la seguridad. Sin
concertados para asegurar ellos. embargo, sólo tiene que dar
Se demuestra que existen fuertes razones lenguaje teórico-
computacionales teóricos y formales para los desafíos de la
1932-8184 / $ 31.00 §do IEEE 2012
490 IEEE Systems Journal, vol. 7, NO. 3, septiembre 2013
en ellos mayor y reconstruir desde cero no es una opción. En entrada nonheuristic. Comenzamos nuestra discusión con la
lugar de condenar este tipo de sistemas basados en su historia validación de SQL, pero también muestran que el mismo
de explotación, se muestra un camino hacia la mejora de ellos, enfoque se aplica a los idiomas más complejos como PKCS #
siempre y cuando sus límites commmunication pueden ser 1 (en la Sección VB probamos que PKCS # 1 es sensible al
identificados, analizados y mejorados de acuerdo con nuestra contexto). También se discuten las fallas en
propuesta.
Nuestro argumento se centra en la aplicación de los
resultados fundamentales cidability de- a los dos desafíos
básicos de la construcción del sistema integrado y distribuido
que respuestas sobre la comunicación entre los componentes:
aceptar entradas y gastos de envío en todos los componentes
de forma segura, y la interpretación idéntica de mensajes
pasados entre los componentes en cada punto final . En
particular, se consideran los siguientes dos puntos de vista
sobre la composición.
1) Monocomponente perspectiva: Un componente en un
sistema complejo debe aceptar entradas o mensajes a
través de una o más interfaces. Esto crea una superficie
de ataque, apalancado por la mayoría absoluta de la
explotación téc- nicas. Discutimos el endurecimiento de
la superficie de ataque de cada componente en contra de
los insumos artesanales maliciosos, por lo que un
componente es capaz de rechazar sin perder la
integridad y exhibir un comportamiento inesperado, en
una palabra, sin ser explotados.
2) perspectiva de varios componentes: Como los mensajes
de cambio de componentes, deben asegurarse de que, a
pesar de las posibles diferencias implemen- tación,
interpretan los mensajes de forma idéntica. Aunque este
requisito parece ser trivialmente necesaria para el
funcionamiento correcto, en realidad diferentes
implementaciones de un protocolo por diferentes
componentes producir variaciones, o alects di-
mutuamente inteligibles, con el mensaje semántico
diferencias enmascarados (y por tanto ignorados) en
intercambios no malintencionada. Una clase más
pequeña, pero importante de técnicas de ataque
aprovecha estas diferencias, y puede conducir a ataques
devastadores como los de X.509 ASN.1 y analizado en
este documento.
La importancia de estos requisitos es un hecho empírico de la
experiencia de seguridad de Internet (ver [1] - [3]), que
nuestro documento pone en perspectiva la teoría sólida.
A. Estructura de este documento

Comenzamos con la motivación de nuestro enfoque en la
Sección II y describimos nuestro caso para el enfoque teórico
del lenguaje formal para la seguridad en vista de las hazañas y
las defensas del estado de la técnica. Se revisan los
formalismos antecedentes necesarios en la Sección III.
A continuación, en la Sección IV, explicamos cómo se
aplican estos malisms lucro generales de explotación de
sistemas informáticos, e ilustran esta aplicación para varias
clases conocidas de técnicas prácticas de explotación. Al
hacer esto, conectamos las clases correspondientes de los
ataques con las propiedades formales del lenguaje de las
estructuras de datos específicos, lo que proporciona una forma
nueva y definitiva para analizar varias defensas sugeridas.
En la Sección V, mostramos cómo aplicar las técnicas
teóricas lenguaje formal para lograr la rigurosa validación de
Sassaman et al .: aplicaciones de seguridad DE teoría del lenguaje FORMAL 491
validación anterior se acerca, y mostrar por qué estos una aplicación ad hoc de entrada en lengua no puede
defectos son importantes para la seguridad práctica. proporcionar todas las propiedades del idioma de entrada
La discusión de defectos nos lleva a la Sección VI, en la como de hecho especificado. En un trabajo más reciente [8],
que se presenta una nueva técnica para el análisis de la hemos demostrado que las variaciones entre las
seguridad de las diferencias entre los dialectos mutuamente implementaciones pueden ser explotados para subvertir la
inteligibles que surgen de diferencias de implementación. interoperación de estas implementaciones, y que la
Esta técnica, árbol de análisis diferen- análisis ential, ambigüedad o
demostró ser una herramienta poderosa para mejorar la 1Esto incluye formatos de archivo, formatos de alambre y otras
auditoría de código y análisis de protocolo. codificaciones, y en scripts idiomas Ing, y el significado convencional del
término, por ejemplo, sistemas concurrentes de estados finitos tales como
En la sección VII, se muestra que los retos y fracasos de protocolos de red y de seguridad.
IDS / IPS, sin duda la forma más común de la seguridad
com- posición, se pueden explicar a través de la equivalencia
computacional del lenguaje teórico. Se concluye con un
resumen de los trabajos futuros.
II. ¿Por qué las necesidades de seguridad Teoría

lenguaje formal
Nosotros postular que la verificación de entrada utilizando
el lenguaje formal de teoría de los métodos, ya sea
simplemente verificar que una entrada a un protocolo
constituye una expresión válida en el protocolo de Gram mar
o también la verificación de la semántica de transformations-
entrada es pasado por alto un componente vital de la
seguridad, pero el protocolo, en particular con respecto a las
implementaciones. En pocas palabras, una implementación
del protocolo no puede ser correcta a menos que reconozca
entrada correctamente, y por otra parte se debe considerar
roto.
verificación de software formal busca demostrar cierta
seguridad propiedades de los cálculos del programa (no pasa
nada malo) y la vida de la conexión (sucede algo bueno, con
el tiempo): si cada putation com- un programa puede realizar
satisface una propiedad particular, el programa es seguro (o,
respectivamente, vivir) con respecto a dicha propiedad [4].
verificación de programas en el caso general es indecidible,
y aunque se han desarrollado muchos enfoques para la
falsificación y la verificación de las propiedades, los
problemas no resueltos y sin solución con la escalabilidad y
la integridad de la verificación de algoritmos han impedido
corrección formal de desplazamiento de pruebas y auditoría
de código como el estándar de oro de la industria para el
aseguramiento de la calidad del software [5]. Sin embargo,
los programas que implementan los protocolos-es decir,
rutinas que operan sobre un bien definido de entrada
idioma1-comparten una característica que se puede
aprovechar para reducir drásticamente sus superficies de
ataque: los idiomas de entrada pueden -y, postulamos, deben,
en general, se hicieron decidible y decidieron de forma
manejable. Se demuestra que este requisito de estar bien
especificado y tractably decidible es de hecho un requisito
fundamental del diseño seguro y, de hecho, su violación es la
fuente de gran inseguridad equipo actual.
Las entradas a los componentes del sistema, tales como
navegadores web, la red
pilas, protocolos criptográficos, y bases de datos se
especifican formalmente en documentos de normas, pero en
general, la manipulación de entrada implementaciones
rutinas analizan las lenguas estas normas especifican de
manera ad hoc. Ataques como el Bleichenbacher PKCS # 1
falsificación [6], [7] muestran lo que puede suceder cuando
subespecificación en una norma aumenta las posibilidades de validación de entrada formales requiere un autómata (en lo
vulnerabilidad en las implementaciones de otra forma sucesivo, analizador) al menos tan fuerte como el idioma de
compatible con los estándares. entrada. Es una presunción útil pensar en una gramática
Sobre esta base, argumentamos que dialectos protocolo en términos de su lugar en la jerarquía Chomsky, y el
mutuamente inteligibles de un protocolo no ofrece procesador y el código de
garantías sobre su funcionamiento L L BE- causar el 2Aunque con excepciones notables, tales como XSLT [11], [12], HTML5 +
Equivalente problema ((G) = (H)) es indecidible cuando G CSS3 (mostrado ser undecidable en virtud de su capacidad para implementar la
Regla 110 [13], [14]), y PDF (por muchas razones, incluyendo su capacidad
y H son gramáticas más potentes que determinista libre de para integrar Javascript [15]).
contexto [ 9], [10]. También observamos que los sistemas
que constan de más de un componente, de facto tienen
contratos de diseño inherentes para la interacción de sus
componentes, pero por lo general no hacen cumplir estos
contratos; ataques de inyección SQL (en adelante SQLIA),
por ejemplo, se producen cuando un atacante presenta una
base de datos con una consulta de entrada que es válido
para la base de datos de forma aislada, pero no válida en el
contexto de la función de la base de datos en una aplicación
más grande.
Dado que los idiomas de entrada bien especificados son en
su mayor parte cidable2 de- (o se pueden hacer de manera), no
hay excusa para no verificar las entradas con las herramientas
que han existido para este propósito exacto durante décadas:
programas de análisis formales. Vamos a examinar la
verificación de entrada desde varios ángulos diferentes ya
través de múltiples clases de computabilidad, destacar los
problemas específicos que surgen cuando los diferentes
programas que interactúan sobre un permiso estándar de las
variaciones idiosincrásicas a esa norma, y demostrar
formalmente cómo restringir el idioma de entrada de un
propósito general componente de sistema (tal como una base
de datos) para que acepte solamente aquellos insumos que está
contractualmente obligada a aceptar.
Dado el reciente advenimiento de demostrablemente
correcta, guaranteed- que terminan combinadores analizador
[16] y generadores de analizadores sintácticos basados en
análisis sintáctico ambas gramáticas de expresión [17] y
gramáticas libres al contexto (CFGS) [18], tenemos que el
objetivo del análisis formal, general de entradas está a nuestro
alcance práctico. Por otra parte, las garantías informales de
reconocimiento de entrada correcta son fáciles de obtener a
través de las bibliotecas comúnmente disponibles y
herramientas de generación de código; alentamos el uso más
amplio de estas herramientas en las implementaciones de
protocolo, como el manejo de entrada incorrecta pone en
peligro otras propiedades de una aplicación.
III. Formalismos fondo

A. Computabilidad límites y la Jerarquía de Chomsky
Noam Chomsky clasificado gramáticas formales en una
jerarquía de la contención de acuerdo con su fuerza expresiva,
que se correlaciona con la complejidad del autómata que
acepta exactamente el lenguaje de una gramática genera, como
se muestra en la Fig. 1 [19].
Dentro esta jerarquía, una clase de autómata puede decidir
un lenguaje equivalente, o una poderosa menos potente, pero
un autómata más débil no puede decidir un lenguaje más
fuerte. Por ejemplo, un autómata de pila puede decidir un
lenguaje regular, pero una máquina de estado finito no puede
decidir un lenguaje libre de contexto. Por lo tanto, la
Fig. 1. jerarquía Chomsky de idiomas de acuerdo con su fuerza expresiva.

Idiomas corresponden a las gramáticas y autómatas de la siguiente manera.
y gramáticas regulares, expresiones regulares, máquinas de
estados finitos; CFGs inequívocos, determinista autómatas de †
pila; CFGs ambiguas, no determinista autómatas de pila; ‡
gramáticas sensibles al contexto / idiomas, lineal acotado autómatas; ††
recursivamente enumerables lenguas, gramáticas sin restricciones, ‡‡
Turing ma-
lomos;
El área sombreada indica las clases para las que el problema de la
equivalencia es decidible.
que aceptan la entrada en términos de fuerza de la máquina,

mientras que ser consciente de su equivalencia.
Recursivamente enumerables son indecidible, lo que
representa un problema grave aplicación: el Turing Ma-
chine que acepta una lengua dada recursivamente numerable,
o lenguaje recognizer3 (que es más fuerte que el contexto
sensible pero más débil que recursivamente numerable),
rechaza cadenas no en el lenguaje y se garantiza para poner
fin a ese idioma, se detiene en un estado de aceptación en
todas las cadenas en el lenguaje, pero o bien rechaza o no
para detener a los insumos no en el lenguaje. Todas las
clases de idiomas son más débiles decidable; su autómatas
equivalente siempre terminan en un estado de aceptar o
rechazar [10], [19]. Un lenguaje de protocolo recursivamente
numerable es por lo tanto un riesgo de seguridad, ya que una
entrada maliciosa que podría provocar su analizador para
dejar de detener una negación-sintáctica de servicio o
realizar el cálculo arbitrario.
Parsers también exhiben ciertas propiedades LIVENESS
seguridad y
(Después de Lamport [4]). La solidez es una característica de
seguridad; un analizador de sonido sólo acepta cadenas en su
idioma correspondiente, y rechaza todo lo demás. La
exhaustividad es una propiedad de vivacidad; un analizador
completo acepta cada cuerda en su idioma correspondiente.
La terminación es también una característica de seguridad;
un analizador de terminación con el tiempo se detiene en
cada cuerda que se le presenten, si esa cadena pertenece a su
idioma o no.
Otros dos problemas decidibilidad influyen en nuestro
análisis: los problemas de equivalencia y de contención
libres de contexto. Dado
3Comparar con el partido decisivo, una máquina de Turing que acepta
cadenas en un recursivo.
dos CFGs arbitrarias, G y H, ambos( mensaje decodificado que el que la fuente destinado a
LGRAMO)L= (
MARIDO ) y transmitir, las acciones las realiza destino es probable que
diverge- quizá de manera significativa, desde la fuente de lo
L (G) ⊆L
(H) son undecidable [10], a excepción de una
construcción particular se detalla en [21]. Los CFGs forman que se esperaba. En la comunicación hu-, es difícil evaluar si
dos conjuntos disjuntos: deterministas y no deterministas, que una respuesta inesperada significa un fallo en la transmisión de
corresponde a los autómatas de pila deterministas y no significado o que la evaluación de la fuente de lo que puede
deterministas respectivamente. Todos CFGs sin esperar el comportamiento
ambigüedades son deterministas [22], y el problema de
equivalencia para CFGs deterministas es decidible (aunque el
problema de contención no lo es) [9].
Cualquier gramática en la que el valor de un elemento en la
cadena influye en la estructura de otra parte de la cadena es al
menos sensible al contexto [23]. Esto se aplica a la mayoría de
los protocolos de red y muchos formatos de archivos, donde
los campos de longitud, por ejemplo, el campo Content-
Length de una cabecera HTTP [24] o el DIH y campos de
longitud de un datagrama IPv4 [25], son comunes. gramáticas
de lenguaje de programación que soportan enunciados de la
forma si B1 B2 entonces, si a continuación, S1 S2 otra cosa,
por ejemplo, Javascript [26], son al contexto libre (en el
mejor) no determinista debido a la ambigüedad de los
problemas que cuelgan introduce otro lugar [27]; si el
conflicto de reducción por desplazamiento se resuelve sin
añadir llaves o sintaxis alternativa (por ejemplo, elif o END
IF), la gramática resultante está libre de noncontext.
Convenientemente, los motores de bases de datos
PostgreSQL, SQLite, MySQL y todo el uso de gramáticas LR,
que son deterministas contexto- libre [28]. Existen pruebas de
membresía para ciertas subclases de LR (por ejemplo, LALR,
LR (k), etc.) y métodos de detección ambigüedad aproximadas
[29]; sin embargo, la determinación de si un CFG arbitraria es
inequívoco es indecidible [30].
B. Modelado de la comunicación desde una perspectiva de

seguridad
Shannon [31] propuso un modelo de diagrama de bloques
para describir sistemas que generan información en un punto y
volver a producir en otro lugar. En ella, una fuente de
información genera mensajes (secuencias extraídas de un
alfabeto); un transmisor codifica cada mensaje en una señal en
una forma apropiada para el canal sobre el que puede pasar
datos, entonces lo envía; un receptor decodifica las señales en
mensajes reconstruidos; y un destino asociado con el receptor
interpreta el mensaje. El problema de ingeniería de maximizar
la eficiencia de codificación motivado el trabajo de Shannon;
consideraba que los significados de los mensajes a medida
fuera del alcance de este modelo de transmisión. Sin embargo,
los científicos sociales como Schramm [32] y Berlo [33]
expandido el modelo de transmisión para incorporar los tipos
de aspectos semánticos de comunicación. Schramm
refundición el destino como un intérprete, que lleva a cabo
acciones de acuerdo con el contenido semántico del mensaje
decodificado, y se sustituye ruta del mensaje unidireccional de
Shannon con un bidireccional uno; Berlo hizo hincapié en la
dificultad de convertir pensamientos en palabras y la espalda,
sobre todo cuando el emisor y el receptor difieren en la
capacidad de comunicación. Estas ideas, junto con la técnica
de Hoare axiomático para la definición del lenguaje de
programación mantics Se- [34], tienen sorprendentes
implicaciones para la práctica de la seguridad informática.
Cuando un destino extrae un significado diferente de un
desde el destino que estaba mal. En informática, SIN decodificación (parsing) algoritmo (M), seguido por (es decir,
EMBARGO, podemos hacer afirmaciones formales sobre las integrado con) oper- subsiguiente
propiedades de destinos (es decir, programas), razón acerca ationsconditional
CDE en el resultado de; →
así, (METRO)
de estas propiedades, y demostrar que un programa es
correcta hasta decidibilidad [34]. Cuando la semántica y la re((M)) · do Nunca es el caso de que simplemente analizar
mi (((M))).
implementación de un programa de destino son una entrada procedente de una fuente no confiable debe dar
Delaware
lugar a la ejecución de código cious Malí-o divulgación no
demostrablemente correcta, si es o no lleva a cabo su función
prevista [34] es una cuestión de si el destino recibe el autorizada de sensible
mensaje deseado. Si la respuesta de un destino verificado al 4Este fenómeno sugiere que la máxima de relación [35] de Grice, sea
mensaje de una fuente M no concuerda con la respuesta de relevante, se aplica a la pragmática de las lenguas artificiales y las naturales.
que la deducción sobre el programa y M predecir, el receptor
ha decodificado algo más que el M que el transmisor
codificado. En la práctica, esta situación es demasiado
frecuente entre las diferentes implementaciones de un
protocolo.
de adaptaciones de Schramm Berlo y dibujaron con razón
críticas por su enfoque en la codificación y decodificación,
lo que implicaba la existencia de alguna métrica para la
equivalencia entre el decodificador de una persona y el
inverso del codificador de otra persona. Sin embargo, en
transmisiones a través de redes de ordenadores, donde tanto
el origen y el destino son máquinas universales de Turing,
podemos probar la equivalencia de estos autómatas si son lo
suficientemente débil; si son no determinista contexto de
libre o más fuerte, su equivalencia es indecidible. Puntos de
codificador-decodificador inequivalence- específicamente, ED D mi
casos en los que, para un mensaje M, una
codificaciónfunción, y una descodificación
función,( ( M E T R O )) METRO- puede hacer ED mi /
que el destino de tomar alguna acción que la fuente no
anticipó. Un atacante que puede generar una señal (M) tal m
ese( (METRO)) = M puede tomar ventaja de esta falta i re
de equivalencia. De hecho, muchas hazañas clásicas, tales Del
como desbordamientos de búfer, implican aw mi
elaboraciónalgunos( METRO) -donde el are
significado de M, en su caso, es irrelevante 4-tal que
aplicando a ( M E T R O ) , o paso( (METRO))
como una entrada al destino, o ambos, provoca una
secuencia de cálculos ventajoso para el atacante (por
ejemplo,
la apertura de un shell remoto).
Naturalmente, un atacante que puede alterar (M) en el m
canal, o que puede modificar M antes de su codificación, i
también puede provocar cálculo inesperado. El primero es un
hombre en el medio de ataque; el último es un ataque de
inyección. Ambos afectan a sistemas en los que el conjunto
de mensajes que la fuente puede generar es un subconjunto
de aquellos sobre los que puede operar el destino.
Tenga en cuenta que no tenemos en cuenta las situaciones Del
en que ((M)) = M, pero diferentes destinos responden a M aw
con diferentes acciones; estos constituyen la semántica del are
programa divergentes, lo que es relevante para el
razonamiento correcto en general, pero fuera del alcance de
este documento. Sólo estamos interesados en la semántica de
D y E.
IV. Hazañas como Computación inesperado

Envío de un mensaje de protocolo es una solicitud para el
equipo de recepción para llevar a cabo el cálculo sobre la
entrada no es de confianza. El equipo receptor realiza la
r
información; sin embargo, esta es la base de la mayoría de los débil entre canales de control y de datos [41] para modificar la
ataques eficaces en sistemas informáticos en red modernos, estructura, y de este modo la semántica de ejecución, de una
especialmente porque permiten, a pesar de que no esperan, la entrada a un componente de aplica- ción [21], [41]. Halfond et
ejecución de algoritmos maliciosos cuando se proporciona la al. [42] enumerar muchas defensas de inyección de heurísticas;
entrada correspondiente. Que este cálculo es inesperado es lo en la Sección VA describimos la validación árbol de análisis,
que lleva a este tipo de vulnerabilidades ser considerado una técnica de defensa verificable. Ahí
hazañas, pero en última instancia, el problema constituye un
fallo en el diseño. Ya sea implícita o explícitamente, los
diseñadores van a trabajar con un contrato [36] en cuenta por
el comportamiento de su software, pero si el código no
establecer y hacer cumplir las condiciones previas para
describir entrada válida, son posibles muchos tipos de
exploits.
Este comportamiento es especialmente perjudicial través de
las capas de AB- straction y sus interfaces correspondientes,
ya que en la práctica estos límites de capas se convierten en
los límites de competencia de los programadores.
A. Los ataques de inyección

ataques de inyección objetivo aplicaciones en los puntos
donde un componente del sistema adquiere entrada de un
usuario con el fin de construir una entrada para otro
componente, tal como una base de datos, un motor de
secuencias de comandos, o el medio ambiente DOM en un
navegador. El atacante artesanía una entrada para el primer
componente que se traduce en la entrada construido producir
algún cálculo en el segundo componente que cae fuera del
alcance de las operaciones el diseñador del sistema destinado
el segundo componente a realizar. Algunos ejemplos:
Ejemplo 1 (Command Injection): Funciones tales como sis-
tema () en PHP, Perl, y C; casi todas las funciones ción de
consulta SQL ejecu-; y eval de JavaScript () tomar como
argumento una representación de cadena de un comando a ser
evaluado en algún entorno de ejecución (en este caso, el shell
del sistema, un motor de base de datos, y el intérprete
Javascript respectivamente). La mayoría de estos entornos
apoyan cálculo arbitrario en su propio derecho, aunque los
desarrolladores sólo tienen la intención de utilizar sus sistemas
de un subconjunto muy limitado de esta funcionalidad. Sin
embargo, cuando estas funciones invocan comandos
construidas a partir de la entrada del usuario no validado, un
atacante puede diseñar una entrada que anexa comandos
adicionales, no autorizados a los pretendidos por el
Developer- que el entorno realiza diligentemente, usando los
mismos privilegios concedidos a los comandos deseados [37] .
Ejemplo 2 (HTTP Parámetro Contaminación): RFC 3986
[38] observa que el componente de consulta de un URI
contiene a menudo pares clave = valor que el servidor receptor
debe manejar, pero especifica nada acerca de la sintaxis o
semántica de tales pares. form-urlencoded tipo de medio de
W3C [39] se ha convertido en el parámetro de facto de
codificación para ambos HTTP GET cadenas de consulta y
cuerpos de mensaje HTTP POST, pero el manejo de
parámetros semántica se deja a la discreción implementador.
comportamiento preferencia idiosincrásica de duplicados de
las llaves, en una cadena de consulta oa través de los canales
de entrada, puede permitir a un atacante sobrescribir los datos
suministrados por el usuario, el comportamiento de control de
aplicaciones web, e incluso filtros de derivación contra otros
ataques [40].
Todos los tipos de apalancamiento inyección una frontera
varias categorías de defensa contra inyección: escape, que [10], es fácil para definir una rutina de validación positiva
trata de transformar la entrada del usuario que pueda alterar [42], que sólo admite la entrada del usuario que no contiene
la estructura de una entrada posteriormente construido en un marcadores de posición de formato.
equivalente literal String; contaminar, que las banderas de Por lo tanto, vemos que el endurecimiento rutinas de
usuario de entrada como no fiable y advierte si esa entrada entrada, por lo que no proporcionan las operaciones
se utiliza en condiciones de riesgo; listas negras de entradas posteriores con argumentos que violan
maliciosos conocidos; y la abstracción programática, que
proporciona acceso de canal de control a través de un API y
relega entrada del usuario para el canal de datos [42]. Otra
técnica, la validación árbol de análisis sintáctico, pases
entradas construye a través de un validador que les analiza,
compara el árbol de análisis sintáctico resultante a un
conjunto de candidato aceptable analizar árboles, y rechaza
las entradas cuya estructura no está en ese conjunto.
B. Otras áreas de ataque

Otros vectores de ataque desdibujan los límites entre los
canales de control y de datos de formas más sutiles; en lugar
de la orientación de los lenguajes de alto nivel que explota
de inyección, que toman ventaja ad- de manejar de entrada
modos de fallo para alterar el código máquina o código de
bytes en un proceso ya de aplicación directa. Muchos de
tales ataques, por ejemplo, ataques shellcode [43], contienen
una secuencia de códigos de operación que se escriben en
una ubicación dentro del espacio de direcciones del proceso
y ejecutadas por medio de un salto desde una dirección de
retorno marco de pila sobrescribe; otras técnicas, tales como,
programación volver orientada retorno a libc [44] y su
generalización [45], [46], sobrescribir la dirección de retorno
para que apunte a una función o un fragmento de código
(también conocido como aparato, por ejemplo, en el la
sección de código de programa,
Ejemplo 3 (Tampón desbordamientos): Cuando una
función diseñada para escribir datos en una región acotada
de memoria (una memoria intermedia) intenta escribir más
datos que la memoria intermedia puede contener, puede
sobrescribir los valores de datos en la memoria adyacente
locations- posiblemente incluyendo la dirección de retorno
marco de pila [48] o estructuras de control montón de un
asignador de memoria [49] - [51]. Con- agotar tales idioma
de entrada de una función de los valores que la función no se
puede transformar en datos de mayor tamaño que el búfer
puede prevenir un desbordamiento, aunque la presencia de
los argumentos de cadena de formato (véase más adelante)
puede complicar las cosas.
Ejemplo 4 (Ataques formato de cadena): Ciertas
funciones de conversión C permiten marcadores de posición
en su argumento cadena de formato que interpolan
argumentos subsiguientes en la cadena de la función
construye. Si un proceso permite a un atacante para poblar el
argumento de cadena de formato, que puede incluir
marcadores de posición que le permiten inspeccionar las
variables de pila y escribir valores arbitrarios a las
posiciones de memoria arbitrarias [52]. Otros lenguajes que
soportan las cadenas de formato presentan vulnerabilidades
similares [53], y lenguajes implementados en C, tales como
PHP, pueden sucumbir indirectamente si la entrada inseguro
alcanza un argumento de cadena de formato en la
implementación subyacente [54]. Afortunadamente, la
sintaxis marcador de posición de C es regular, y puesto que
los lenguajes regulares son cerrados bajo del complemento
6Su y Wassermann [58] llegaron independientemente en la misma

precondiciones esas operaciones o fallar en formas que construcción. 7reglas de producción no utilizados se eliminan, al igual que las
permiten a un atacante ejecutar código
| arbitrario, está en el alternativas no utilizados de reglas de producción retenidas. Si la regla A :: =
⇒
centro de todas las prácticas de codificación defensivas. A BC aparece en la gramática, pero la buena conocida conjunto sólo requiere de la
aplicación de laC.A. rama, la regla
continuación se examina en detalle la mecánica de la subgrammar correspondiente es A :: = C. Tenga en cuenta que para gramáticas
validación de los idiomas de entrada de diversas clases de una donde un no terminal cuyo lado derecho contiene aparece más de una
manera comprobable y manejable. alternativa en el lado derecho de más de un no terminal que aparece en los
análisis sintácticos de conocido- buenas consultas, estas alternativas deben
distinguirse en
la subgrammar.
V. Entrada demostrablemente correcta
Validación
A pesar de la mayor parte del trabajo en esta área se centra
en los ataques de inyección, la validación de entrada teórica
lenguaje formal ofrece protecciones de seguridad contra una
gama mucho más amplia de exploits. Cualquier ataque que
explota el análisis de un proceso tal que acepta una entrada
que no se ajusta a la gramática válida del protocolo previsto
puede y debe prevenirse a través estricta validación de
entradas.
A. Los ataques de inyección y Validación Analizar árbol libre

de contexto
Dejector [21] presenta un árbol de análisis independiente
del contexto validación enfoque ción a la prevención de
SQLIA.5 Se introdujo una construcción formal para
sublenguas restringidas de SQL; 6 usando este enfoque, la
validación de una consulta SQL consiste en probar que para
ser miembro de la sublenguaje. Dado un conjunto de buena
conocida consultas derivadas, por ejemplo, a partir de las
plantillas de consulta de cuerda-interpolada que un
programador de aplicaciones ha definido para una aplicación
en particular y la gramática formal para el dialecto apropiado
de SQL, Dejector transforma la gramática SQL en una
subgrammar que contiene sólo las normas requeridas para
producir exactamente las consultas en las buenas conocida
Cuerdas set.7 reconocidos por la subgrammar se garantiza que
sea estructuralmente idénticas a las de la puesta a punto de un
conocido buena métrica validez atestiguado en toda la
literatura ataque de inyección ture [57], [58]. El subgrammar
continuación, se utiliza con un generador de analizador como
el bisonte o antlr para producir un reconocedor para el
sublenguaje. Notablemente, este autómata es exacta en lugar
de heurística (como en [55]) o aproximada (como en [59] y
[60]), y tiene el efecto de optimización de la comparación de
consultas entrantes a todos conocido buenas estructuras
simultáneamente.
Las investigaciones posteriores han producido mejoras en el
enfoque original, centrada principalmente en identificar el
conjunto legítima-consulta inicial y la validación automática
integrar en una aplicación. Por desgracia, cada uno de estos
esfuerzos adolece de defectos que les impiden garantizar la
validación correcta o comportamiento de la aplicación
correcta. Éstas incluyen:
5La técnica fue descubierta independientemente por varios equipos de
investigación. Referencias [55] y [56] publicaron enfoques similares en todo

el mismo tiempo; [57] popularizaron la idea, pero Dejector hasta ahora se ha
pasado por alto en su mayoría por la comunidad académica debido a su
publicación en una conferencia de hackers. Esto es, a nuestro entender, la
primera descripción revisada por pares de Dejector, con un énfasis en las
características que lo distinguen de los intentos posteriores de poner en
práctica estas ideas centrales.
1) Autómata suficientemente fuerte: Varios validadores SQL ANSI 92 estándar, aumentada con extensiones de
basados automata- [59] - [63] modelo el conjunto de lenguaje MySQL-específicos; SQLPrevent [65] utiliza ANSI
consultas aceptables usando una máquina de estado finito, SQL, pero no menciona qué versión. Otros sólo afirman que
siguiendo el enfoque de Christensen et al. [64], en el que el las gramáticas que utilizan son [58], [69] independiente del
análisis estático de las llamadas a métodos que emiten contexto, [70].
consultas SQL produce un gráfico de flujo que representa Si bien es posible demostrar la equivalencia de las dos
posibles cadenas generadas, que luego se amplió a un gramáticas LR, ninguno de estos autores no han aportado
lenguaje regular para tratabilidad. Sun y Besnozov pruebas de equivalencia de sus gramáticas de aplicación y el
identificar los casos en que tales modelos FSA generar SQL
informes falsos positivos [65], y de hecho Wassermann et al.
concede que su aproximación del conjunto de las cadenas de
consulta legítimos es excesivamente permisiva. Sin
embargo, afirman:
En la práctica, no encontramos una función que
concatenación Nates alguna cadena, el valor de
retorno de una llamada recursiva a sí mismo, y la
otra cadena (que sería la construcción de un { }
lenguaje como (NA) n), por lo que esta etapa de
ensanchamiento no hace daño la precisión del
análisis.
Nosotros examinado la gramática bisontes que genera el
analizador Post-greSQL y, lamentablemente, descubierto
cuatro de estas funciones. Los lados de la derecha de las
normas de producción SE- Lect con parens y se unieron
tabla contiene la sintaxis precisa paréntesis de equilibrio que
Wassermann et al. No creído encontrar en la práctica.
paréntesis desequilibradas solo son suficiente para
desencadenar esas vulnerabilidades clasificadas en la
taxonomía de Halfond et al. consultas como ilegales /
lógicamente incorrectos [42].
Las demás funciones que encontramos son más sutiles y
más preocupante. El lado derecho de la expr producción
com- mon mesa, que puede preceder SELECT, INSERT,
FECHA UP- o DELETE, contiene la secuencia '('
PreparableStmt ')'; un PreparableStmt es en sí mismo un
SELECT, INSERT, UPDATE o DELETE. Además, las una
expr y c producciones expr, que reconocen unario, binario, y
otras expresiones tales como X no NULL, x como y, y todas
las expresiones aritméticas-son cursiva mutuamente re-.
Estas producciones aparecen a lo largo de la gramática
PostgreSQL, y son los objetivos gramaticales de casi todas
las categorías de SQLIA, dado que los insumos
suministrados por el usuario normalmente uso corresponden
a las producciones en el lado derecho de una una expr.
Por lo tanto, mientras que las herramientas que utilizan
esta metodología han obtenido buenos resultados contra
suites SQLIA como el banco de pruebas AMNESIA [66],
[67], se cuestiona su eficacia contra los ataques que se
dirigen deliberadamente a la falta de concordancia entre un
modelo FSA generado y una gramática SQL subyacente.
2) validador y la Base de Datos de utilizar diferentes
gramáticas: Muchos enfoques de validación árbol de análisis
representan adecuadamente el conjunto de estructuras
aceptables utilizando un CFG, pero derivan su estructura
aceptable ajustar desde una gramática distinta de la del
sistema de base de datos destino, posiblemente, la
introducción de una falta de concordancia. SQLGuard [56]
compara analizar árboles de consultas ensamblados con y sin
la entrada del usuario, utilizando el analizador ZQL [68];
CANDID [57] utiliza un analizador SQL estándar basado en
dialectos que tienen como objetivo validar. Dejector elude 6) Hasta que se alcance q0, o se alcanza el final del extremo
este problema utilizando directamente léxico y la gramática de derecho de la cinta, aplicar el siguiente procedimiento.
PostgreSQL bisonte. inconveniente de de- JECTOR es que su a) Consumir un octeto.
implementación se acopla no sólo a la distribución de la base b) qn → qn-1.
de datos, pero la revisión analizador específico; sin embargo,
se evita que un atacante la construcción de una entrada que da
directamente al validador, pero produce un comportamiento
no deseado cuando llega a la base de datos. Como un ejemplo,
CVE-2006- 2313 y CVE-2006-2314 describen una
vulnerabilidad relevante en PostgreSQL codificaciones
multibyte [71], [72]. Un atacante podría crear una cadena que
un validador de codificación-conscientes (es decir, uno que
asume de entrada para estar en ASCII, Latin-1 o alguna otra
codificación byte simple) acepta, pero que un servidor
utilizando una codificación multibyte (UTF-8, Shift-JIS, etc.)
analiza de una manera tal como para poner fin a una cadena
literal temprano.
B. Analizar árbol Validación En el contexto-sensible Idiomas

Bleichenbacher [6] presenta una firma de ataque contra la
falsificación RSA PKCS # 1 implementaciones que no validan
correctamente los bytes de relleno. Se demuestra que PKCS #
1 es sensible al contexto y se puede validar de la misma
manera como SQL, utilizando una representación atributo de
la gramática [73].
Teorema 1: PKCS # 1 es sensible al contexto.
Lema 1: Límite superior: un autómata linealmente acotado-
para PKCS # 1.
Prueba: Sea P = wn { W| es un octeto hexadecimal, N es el
tamaño del módulo RSA en bits, y = WN '00' '01' 'FF'norte-len
(hash) -len (de) -3 '00' hash de digerir que codifica, donde
DIGEST-codificación es una cadena ∈ {} fija 0, 1 como se

especifica en RFC 2313 [74] y el hash es un ∈ {}
mensaje de hash
0, 1 de longitud apropiada para }el digesto-codificación.
Definimos un autómata acotado lineal-, AP, que sólo acepta
cadenas en P. La longitud de la cinta de AP es n, y tiene
estados q0, q1, ... Q67 y un estado rechazar, QR. Q67 es el
estado de inicio.
1) Ir a la celda más a la izquierda en la cinta.
2) Consumir octeto 00 y la transición al estado q66. Si
cualquier otro octeto está presente, la transición a qR y
alto.
3) Consumir octeto 01 y la transición al estado Q65. Si
cualquier otro octeto está presente, la transición a qR y
alto.
4) Consumir octetos FF hasta que se observa cualquier otro
octeto, y la transición a Q64 estado. (Si el primer octeto
que sigue al 01 es otra cosa que no sea FF, la transición
a qR y alto.)
5) Simular coincidencia de expresión regular de las
cadenas de codificación digest- fijos (como se describe
en la gramática con atributos en la siguiente subsección)
durante los próximos 15-19 octetos como sigue.
a) secuencia MD2 → Q15.
b) secuencia MD5 → Q15.
c) SHA-1 secuencia → q19.
d) SHA-256 secuencia → q31.
e) SHA-384 secuencia → P47.
f) SHA-512 secuencia → Q63.
g) No hay resultados → QR.
7) Si en q0 Estado y la cabeza de la cinta está en el para n arbitraria:

(S) = 00 :: 01 (FFS) 00 (ASN.1)
extremo más a la derecha de la cinta, aceptar. De lo Válido((S)) ← Válido ((ASN.1)) y Len ((FFS)) = n - Len ((ASN.1)) - 3
contrario, rechazar. (FFS) :: = FF FF FF FF FF FF FF FF
Len ((FFS)) ← 8
Debido a que P puede ser descrita por un autómata | (FFS) 2 FF
delimitado lineal, por lo tanto, es a lo más sensible al Len ((FFS)) ← (LEN ((FFS) 2) + 1)
contexto.
Lema 2: Límite inferior: PKCS # 1 no es independiente del
contexto.
Prueba: Nosotros muestran que P es utilizando el
lema de bombeo libre de contexto, que establece que si L
es un lenguaje libre de contexto, cualquier cadena s l de al ∈
menos la longitud de bombeo p se puede dividir en
subseries vwxyz tales sin noncontext que wy> 0, wxy p, y ||| | ≤ ≥ ∈
para cualquier i 0, vwixyiz a [10].
Como se indicó anteriormente, n es el tamaño del módulo
RSA en bits. (N puede variar de un caso a otro; diferentes
usuarios tendrán diferente- tamaño módulos RSA, pero la
gramática es la misma sin importar el tamaño de n.) Ni w ni
Y pueden ser cualquiera de los bits fijos, 00, 01 y 00 , ya que
la cadena resultante sería demasiado tiempo para estar en P.
Tampoco se puede w o Y corresponden a cualquier parte de
la almohadilla, como el lema de bombeo requiere que W e Y
puede ser bombeado un número arbitrario de veces, y,
finalmente, la longitud del hash solo excedería n. De hecho,
desde n es fija, la única manera para bombear s sin obtener
una cadena que es demasiado largo o demasiado corto sería | |≥
si ambos W e Y eran la cadena vacía. Sin embargo, el lema
de bombeo requiere que wy 0, y por lo tanto P no puede ser
libre de contexto. Puesto que P es como máximo sensible al
contexto y debe ser más fuerte que libre de contexto,
1) Un atributo Gramática para PKCS # 1: gramáticas de
atributos y análisis sintáctico de expresión gramáticas [75]
son formalismos de hormigón que se utilizan comúnmente
para implementar analizadores y generadores de lenguajes
sensibles al contexto. Analizar las gramáticas de expresión
puede describir algunos lenguajes sensibles al contexto, por {≥ }
ejemplo, la anbncn conocido: n 1, pero no todos ellos;
atribuir gramáticas son suficientes para describir cualquier
lenguaje sensible al contexto. Como se señaló Finney, el
relleno Bleichenbacher en- tachuela produce cadenas que las
implementaciones vulnerables interpretados como
codificaciones válidas, pero que no son en realidad
miembros de P porque tienen muy pocos bytes de relleno y
datos adicionales más allá del hash del mensaje. Por lo tanto,
un sonido y analizador completa basada en atributos
gramática para PKCS # 1 funciona como un validador para
PKCS # 1 y derrota al ataque Bleichenbacher rechazando sus
cuerdas hechas a mano. Desde el ataque de seguimiento de
Izu et al. También asume el mismo error de implementación
como en el ataque original, nuestra validador también
derrota a su ataque matemáticamente más sofisticado.
Tenga en cuenta que aquí se describe un validador para
PKCS # 1 en su totalidad, en lugar de un sublenguaje
restringido de P. Se podría definir un sublenguaje restringido
de P -por ejemplo, uno que no admite el MD5 y MD2 de
hash funciones- desaprobado por la poda de las reglas de
producción correspondientes y cualquier alternativa que
contienen referencias a ellos, pero aquí nos centramos en el
lenguaje en su totalidad.
La siguiente gramática con atributos, donde T representa ()
cualquier octeto válido desde 00 a FF, genera cadenas en P
(ASN.1) :: = (Digest-Algo) (Hash) La respuesta de destino a( (METRO)) incluye cálculos que

Válido((ASN.1)) ← (HashLen ((Digest-Algo)) = Len DelEl conjunto
((Hash)))
su respuesta a M no tendría.
aw
Len ((ASN.1)) ← (Len ((Digest-Algo)) + Len ((Hash))) are
(Digest-Algo) :: = (MD2)
HashLen ((Digest-Algo)) ← HashLen {MA ∪ MB | MA / =DB(EA (MA)), MB DA (EB
((MD2)) (MB))}
Len ((Digest-Algo)) ← 18 especificación o un error de aplicación.
| (MD5)
Mirando hacia atrás a la obra de Shannon et al. en la Sec-
HashLen ((Digest-Algo)) ← HashLen
((MD5)) Len ((Digest-Algo)) ← 18 ción III-B, el objetivo de un ataque diferencial árbol de análisis
| (SHA-1) es encontrar combinaciones de Msource, eSource y
HashLen ((Digest-Algo)) ← HashLen Ddestination tal que M / D = (E (M)), con M semánticamente
((SHA-1)) Len ((Digest-Algo)) ← 15
| (SHA-256) válidos para la fuente
HashLen ((Digest-Algo)) ← HashLen y D (E (M)) semánticamente válida para el destino, donde el
| (SHA-384)
HashLen ((Digest-Algo)) ← HashLen
| (SHA-512)
HashLen ((Digest-Algo)) ← HashLen ((SHA-512))
Len ((Digest-Algo)) ← 19
(MD2) :: = 30 20 30 0C 06 08 2A 86 48 86 F7 0D 02 02 05 00
04 10
HashLen ((MD2)) ← 16
(MD5) :: = 30 20 30 0C 06 08 2A 86 48 86 F7 0D 02 05 05 00
04 10
HashLen ((MD5)) ← 16
(SHA-1) :: = 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14
HashLen ((SHA-1)) ← 20
(SHA-256) :: = 30 31 30 0D 06 09 60 86 48 01 65 03 04 02 01
05 00 04 20
(SHA-384) :: = 30 41 30 0D 06 09 60 86 48 01 65 03 04 02 02
05 00 04 30
(SHA-512) :: = 30 51 30 0D 06 09 60 86 48 01 65 03 04 02 03
05 00 04 40
(Hash) :: = (T)dieciséis
Len ((Hash)) ← 16
| (Hash) 2 (T)
Len ((Hash)) ← Len ((Hash) 2) + 1
VI. Analizar árbol de análisis diferencial

Nosotros observar que, mientras que diferentes
implementaciones de la misma especificación deben procesar
la entrada y realizar tareas en efectivamente la misma manera
que el uno al otro, a menudo es el caso de que diferentes
implementaciones analizan entradas al programa (o mensajes
pasados internamente) de manera diferente dependiendo de
cómo la especificación se interpretó o implementado. Tales
implementaciones proporcionan distintos dialectos de un
protocolo. Si bien estos dialectos pueden ser mutuamente
inteligible con el propósito de intercambiar información no
malintencionada, los supuestos anteriores seguridad pueden
fallar.
Hemos desarrollado una técnica poderosa para mejorar la
auditoría de código y análisis de protocolo, conocido como el
árbol de análisis dife- ataque ferential [8], en el que damos dos
implementaciones diferentes de los idénticos parámetros de
estado y entrada misma especificación, considere sus
decodificaciones como hormigón analizar los árboles, y
enumerar las diferencias entre los árboles. Desviaciones entre
los árboles indican problemas potenciales, por ejemplo, un
área de discreción implementador debido a la ambigüedad
particionar el conjunto anonimato [79].
describe un límite inferior en el conjunto de vulnerabilidades
presentes en la superficie de ataque del sistema compuesto
que tiene taciones aplica- (es decir, procesos) A y B como
puntos finales de un canal común (después de Howard et al.
[76]).
A. Descubrimiento superficie de ataque

Nosotros han utilizado casos extremos identificados por
análisis diferencial árbol de análisis sintáctico para aislar
vulnerabilidades graves en X.509 [77]. Encontramos muchos
casos en los que dos implementaciones del sistema X.509 se
comportaban de manera diferente cuando se les da la misma
entrada, de tal manera que estas diferencias llevaron a una
autoridad de certificación firmar un certificado que ver como
se conceda un privilegio, mientras que el lado del cliente
aplicación (el navegador web) analiza la misma entrada de
una manera flexible diferentes afirmaciones de seguridad, lo
que lleva a un compromiso del sistema [8].
Ejemplo 5 (Null Terminator Ataque): El atacante presenta
una solicitud de firma de certificado a una autoridad de
certificación (CA) que leerá el nombre común como \
www.paypal.comx00. badguy.com y devolver un certificado
firmado por este tema CN. El mensaje que este certificado
representa es M, y el propio certificado es de (M). Ahora mi
presentes (M)) a un navegador vulnerable al ataque
terminador nulo. Aunque el valor del campo CN en la que M mi \
eswww.paypal.com x00.badguy.com, su valor en ((M)) es de Del
www.paypal.com. aw
En este caso, el decodificador en el CA interpreta are
correctamente el CN como una cadena tipo Pascal (que \
puede incluir el carácter x00), compara la lectura de la CN
con las credenciales presentadas por la fuente, y responde
con una codificación de un mensaje la incorporación de este
CN válido-pero-peculiar. Lo que no sabe el destino,
decodificadores otros destinos interpretan la CN como una \
cadena de estilo C, para lo cual x00 es un indicador de final
de cadena, y decodificar la codificación de la AC en un
mensaje firmado que acrediten que el certificado es válido
para www. paypal.com!
B. Otras aplicaciones de Parse árbol Diferenciales

En algunos lugares, los aspectos de la implementación del
protocolo de divergencia son particularmente delicada; un
buen ejemplo son los sistemas de anonimato. El trabajo
previo ha demostrado que el anonimato proporcionado por
una herramienta de capa inferior puede verse comprometida
si mayores diferencias de capa se revelan a un atacante;
herramienta ticlick Panop- del FEP se muestra cómo utilizar
los identificadores del navegador web para sacar ventaja de
las garantías ofrecidas por los sistemas de anonimato de bajo
nivel, tales como Tor [78]. La posibilidad de que un atacante
para realizar análisis diferencial árbol de análisis sintáctico
de las implementaciones de aplicaciones comunes de los
clientes de protocolos estándar, a priori, le permite generar
un libro de códigos de clases, que consiste en las entradas
que, cuando se envía al usuario desprevenido,
desencadenarán cliente del usuario (web navegador, etc.)
para responder de una manera que permita al atacante para
Un medio más indirectos del uso de los diferenciales de facto entre el IDS y las unidades de tratamiento de entrada de
árbol de análisis sintáctico como oráculos aparece en la obra destino. El primer trabajo [82] para demostrar exhaustivamente
de Clayton en el sistema CleanFeed contra la pornografía de la debilidad fundamental de los sistemas de detección de
British Telecom [80]. Se construye paquetes TCP con un valor intrusiones de red (NIDS) fue, como era previsible, en base a
TTL elegido especialmente que, si se utiliza realmente, intuiciones hackers. Estas intuiciones probablemente fueron
permitiría la obtención de un comportamiento de redirección informados por el uso previo de diferencias de implementación
de tráfico- del sistema proxy de CleanFeed contra el pila TCP / IP para la toma de huellas dactilares en el sistema
comportamiento del tráfico noninterdicted que ponga de
manifiesto de forma selectiva con exactitud qué direcciones IP
materiales alojada que BT estaba tratando de bloquear!
En particular, el ataque de Clayton hace uso de tres
protocolos TCP, IP, ICMP y separadas-siendo utilizado por
varios sistemas (BTS de un usuario, y la de un sitio
prohibido). Esta alta se enciende la observación empírica bien
conocido que los sistemas compuestos tienden a tener
comportamientos característicos que resultan de la
composición y no son, evidentemente, inherente a los
componentes individuales. En aplicaciones críticas (por
ejemplo, un sistema de anonimato utilizada para evadir la
represión violenta), estos comportamientos pueden ser
mortales. Para citar una máxima hacker, Composición Veces.
1) Una orden bien definido en Parse árbol Diferenciales:
Con- Sider diferencial de un ataque al árbol de análisis
ejecutado entre dos implementaciones diferentes de un mismo
protocolo de un árbol de análisis diferenciales de orden cero.
Dispone de dos pasos, el protocolo de codificación y
decodificación de protocolo.
Ahora considere un ataque diferencial árbol de análisis
ejecutado entre dos implementaciones diferentes de dos
protocolos diferentes,→pro ejemplo, HTTP ASN.1. (Por
ejemplo, X genera ASN.1 que se transforma en HTTP que se
analiza por Y). La transformación entre un protocolo y otro es
un punto de interés; puede, por ejemplo, ASN.1 malformado
ser generada con respecto a la función de transformación a
HTTP tal que Y realiza algún cálculo inesperado? Se trata de
un árbol de análisis diferencial de primer orden. Tiene tres
pasos: protocolo de codificación, la transformación de
protocolo (el protocolo ') y el protocolo' decodificación.
La construcción se extiende de forma recursiva.
VII. ¿Por qué Johnny no puede detectar

Una forma discutible nonprincipled pero en la práctica
común de la composición es el de la adición de un sistema de
detección de intrusiones / prevención (IDS) a un objetivo
conocido por ser susceptible a la explota- ción. El IDS vigila
las entradas y / o el estado del objetivo, los modelos de
cálculo del objetivo, y se espera que para atrapar a los
exploits. Este diseño, obviamente, depende de la capacidad
del IDS para que coincida con al menos aquellos aspectos del
proceso de entrada del objetivo que sirven como vectores de
ataque; sin tal coincidencia de la IDS no reduce la
inseguridad, y de hecho puede aumentar mediante la adición
de errores explotables de su propio. Lejos de ser meramente
teórica, esta última es una dura realidad bien conocida por los
profesionales de seguridad tanto en el lado de ataque y
defensa (ver [81]).
La magnitud del lenguaje teórico y computacional del reto
que supone la construcción de un juego tan eficaz en este
diseño de facto compuesta debe ahora ser claro para el lector,
ya que requiere acercarse a la equivalencia computacional de
herramientas como Nmap, Xprobe y hping2 (por ejemplo, Forrest, Somayaji

[83] explora metódicamente las diferencias en la respuesta
del sistema operativo pilas de red a varias características
ICMP). La investigación posterior estableció que la única
esperanza de hacer frente a esta debilidad era ing Match-
precisa de la sesión de cada objetivo (re) lógica montaje por
el NIDS (por ejemplo, [84] - [86]).
En los sistemas de detección de intrusiones basado en
host, el problema de hacer coincidir el cálculo defensa con el
cálculo objetivo no es menos pronunciada. Por ejemplo,
Garfinkel [87] enumera una serie de trampas y las trampas
de la implementación de un monitor de referencia de
supervisión de la llamada al sistema y advierte que duplicar
la funcionalidad OS / código debe ser evitado a toda costa.
Observamos que el aislamiento de la lógica monitor de
referencia del resto del sistema parecería ventajoso si fuera
posible validar la coincidencia entre el propio cómputo del
sistema y el aislado, cómputo duplicado; Sin embargo, como
hemos visto, tal validación podría ser fácilmente indecidible.
En una palabra, el endurecimiento de un sistema débil por
lo componen con un monitor que reproduce el cálculo
conocido o sospechado de ser intentos probables vulnerables
para convertir un tipo de entrada y validación de un
problema indecidible en un cálculo equivalencia indecidible
problema apenas una mejora en el largo correr, a pesar de
que inicialmente podría parecer a ganar algo de terreno
contra ataques conocidos. Sin embargo, deja intacta la causa
principal de la inseguridad del objetivo, y no debe por lo
tanto ser considerada como una solución viable.
Un enfoque común para el comportamiento del programa
de modelado implica secuencias de llamadas al sistema [88],
[89]. Debido a que las llamadas al sistema representan el
método por el cual los procesos afectan al mundo exterior, se
cree que estas secuencias para proporcionar la noción más
tangible del comportamiento del sistema. A pesar de su
aparente éxito en la detección de anomalías debido a
ataques, estos modelos tienen varias deficiencias, incluyendo
la susceptibilidad al mimetismo ataques [90]; un atacante
puede mantener el sistema dentro de algunos épsilon de los
patrones normales durante la ejecución de las llamadas de su
elección. Este problema se sugiere que deberíamos
investigar la extracción y el uso de una noción más preciso
de la actividad del programa. Tenga en cuenta que nuestro
objetivo no es criticar enfoques llamada al sistema por ser
susceptibles a ataques de mimetismo; en lugar,
Los sabores populares de modelo o detec- ción de intrusos
basados anomalía a menudo ofrecen mucho muy pequeños
deltas entre sí; Taylor y Gates [91] proporcionan una buena
crítica de los enfoques actuales, y un trabajo reciente de
Sommer y Paxson también explora las razones por las que
nosotros como comunidad no podríamos utilizar con éxito el
aprendizaje de máquina para la detección de intrusos [92]. El
enfoque predominante a la detección (secuencias de
llamadas al sistema a juego) es una forma glorificada de la
cadena coincidente expresión regular criticado
frecuentemente utilizado en los sistemas basados en firmas
mal uso como Snort y Bro.
Un número impresionante de RAID, CCS, y los papeles
de Oakland ha derramado mucha tinta digital que ofrece
leves giros o mejoras en la llamada al sistema modelo de
secuencia original propuesto por Denning y madurado por
et al. [88], [93], [94]. Este envase de seguimiento del trabajo

considera, a su vez, cambios que incluyen: secuencias más VIII. Trabajo futuro
largas, las secuencias con más información de contexto (por
ejemplo, puntero de instrucción en el momento de la llamada, Nuestro trabajo futuro se integrará el trabajo existente en la
los argumentos, la máquina de estado registro de la CPU, generación de analizadores verificables, garantizada por
conjuntos de archivos abiertos y recursos), anómalo terminación [16] - [18] con la verificación de los sistemas
argumentos de llamada del sistema, la validación cruzada de concurrentes de estados finitos y el trabajo
las secuencias de la llamada al sistema a través de sistemas
operativos, y otros diversos cambios insignificantes en la
información que se examina como la base de un modelo.
El siguiente paso más natural era intentar caracterizar el
comportamiento normal, comportamiento anormal, y el
comportamiento malware utilizando estructuras de gráfico de
flujo de control. Desde esta perspectiva, las secuencias de
llamadas al sistema son gráficos muy simples con una relación
lineal.
Por desgracia, este movimiento hacia modelos más
complicados de lo que representa el comportamiento de
ejecución revelan cuán limitada estamos en nuestro éxito
esperado. Cuando se ve desde el patrón de la equivalencia del
lenguaje teórico, este estilo de tección de intrusos de- es
esencialmente un problema de adaptar las gramáticas, y sufre
de las mismas limitaciones como prueba de que dos
implementaciones de protocolos de complejidad suficiente
realidad aceptan las mismas cadenas.
La comunidad de detección de intrusos da a este punto de
vital importancia en la búsqueda de modelos resentativas cada
vez más eficientes o tantes de comportamiento malicioso (o
benigno). Añadiendo adornos incrementales a un modelo de
lenguaje no dará lugar a un avance espectacular de nuestra
capacidad para detectar putation com- malicioso; sólo puede
servir para aumentar la complejidad del lenguaje y por lo tanto
aumentar la dificultad de demostrar que el modelo en
particular acepta alguna noción precisa de maliciosa o
anormal. Este es un resultado contrario a la intuición:
iniciativas para mejorar la potencia de un modelo de IDS en
realidad en detrimento de su capacidad para reconocer de
forma fiable el comportamiento equivalente. En este caso, más
potentes mapas a menos fiables.
Nosotros en cuenta que, a lo mejor de nuestro conocimiento,
Schneider [95] se acerca más a considerar los límites de
aplicabilidad política de seguridad como un fenómeno teórico
lenguaje de la teoría de la computación y formal, haciendo
coincidir los objetivos políticos deseados tales como la
memoria limitada o disponibilidad en tiempo real a clases de
autómatas capaz de garantizar la aceptación o rechazo de las
respectivas cadenas de eventos. En particular, los autómatas
Buchi se introducen como una clase de autómatas de
seguridad que puede terminar ejecuciones inseguros definidas
por la propiedad de seguridad de la Lamport: trazas de
ejecución excluidos de la política se pueden caracterizar como
que tiene un conjunto (finito) de malas prefijos (es decir, , hay
una mala ejecución con prefijo traza se considerará seguro).
El enfoque de Schneider conecta las políticas de seguridad
de obligado cumplimiento con las propiedades del lenguaje de
la teoría de idioma del sistema de seguimientos de sucesos.
Observamos que el siguiente paso es considerar este lenguaje
es un idioma de entrada al autómata Imple- Menting el
mecanismo de la política, y para enmarcar sus capacidades de
aplicación como un problema de reconocimiento de idioma
para tales lenguajes traza.
publicación.
de Bhargavan et al. [96] en el uso de tipos de refinamiento [19] N. Chomsky, “En ciertas propiedades formales de las gramáticas,”
para llevar invariantes de seguridad (y, por condiciones Inform. Comput./Inform. Control, vol. 2, pp. 137-167, 1959.
previas extensión, de entrada de idioma) con el fin de [20] T. Berners-Lee y N. Mendelsohn. (2006). La Regla de alimentación al
final, Tag Finding [En línea].
desarrollar una pila de red verificado completo que es de Disponible:http://www.w3.org/2001/tag/doc/ leastPower.html
composición correcta de extremo a extremo. También [21] RJ Hansen y ML Patterson, “armas y mantequilla: Hacia axiomas
tenemos la intención de aprovechar el trabajo previo en la formales de validación de entrada”, en Proc. Sombrero negro reuniones
informativas, 2005.
comprobación de la implementación automatizado, como
Aspier [97], para desarrollar herramientas de análisis
diferencial árbol de análisis automatizado (similares a
fuzzers inteligentes) para el beneficio de los auditores de
seguridad.
Reconocimiento
Los autores desean agradecer a E. Feustel por sus observa-
ciones sobre la seguridad de los sistemas compuestos, D.
Kaminsky por su colaboración en el análisis de fallas en
programas de análisis ASN.1,
A. Bogk, R. Farrow, D. McCardle, J. Oakley, F. Piessens, A.
Shubina, y SW Smith por sus útiles sugerencias sobre
versiones anteriores de este documento, y N. Borisov, N.
Kisserli,
F. Lindner, D. McIlroy, y D. Molnar por sus conversaciones
interesantes durante el proceso de esta investigación.
referencias
[1] D. Geer, “cumplimiento vulnerables”, entrada:. El USENIX Mag, vol.
35, no. 6, Dic de 2010.
[2] F. “FX” Lindner, “El efecto observador comprometida,” McAfee
Security J., vol. 6, 2010.
[3] DJ Bernstein, “Reflexiones sobre la seguridad después de diez años de
qmail 1.0”, en Proc. ACM CSAW, 2007, pp. 1-10.
[4] L. Lamport, “La demostración de la corrección de los programas de
multiproceso,” IEEE Trans. N del software. Eng., Vol. 3, no. 2, pp.
125-143, marzo de 1,977 mil.
[5] R. Jhala y R. Majumdar, “la verificación de modelos de software”,
ACM Comput. Surv., Vol. 41, no. 4, 2009.
[6] H. Finney, “RSA falsificación de la firma de Bleichenbacher basa en
el error mentación imple-”, de agosto de 2006.
[7] T. Izu, T. Shimoyama, y M. Takenaka, “Extender ataque falsificación
de Bleichenbacher,” Informe a J.. Proceso., Vol. 16, pp. 122-129, Sep.
de 2008.
[8] D. Kaminsky, ML Patterson, y L. Sassaman, “pastel de capas PKI:
Nuevos ataques de colisión contra la infraestructura X.509 global”, en
Criptografía financiera. Berlín, Alemania: Springer, 2010, pp 289-
303..
[9] GRAMO. Se'nizergues, “L (A) = L (B)? decidibilidad resultados de
los sistemas formales completos “, Theor. Comput. Sci., Vol. 251,
núms. 1-2, pp. 1-166, 2001.
[10] M. Sipser, Introducción a la Teoría de la computación, segunda ed.,
Inter- nacional ed. Clifton Park, Nueva York: Thompson Course
Technology, 2006.
[11] S. Kepser, “Una prueba simple para el Turing-integridad de XSLT y
XQuery”, en Proc. Marcado extrema Lang., 2004.
[12] R. Onder y Z. Bayram “versión 2.0 XSLT es Turing completo: Una
prueba puramente de transformación en base”, en Proc.
Implementación Appl. Autómatas, LNCS 4094. 2006, pp. 275-276.
[13] E. Fox-Epstein. (2011, marzo). Experimentaciones con el extracto
Máquinas
[En línea]. Disponible: https://github.com/elitheeli/oddities
[14] M. Cook, “universalidad en autómatas celulares elemental,” Syst
Complex., Vol. 15, no. 1, pp. 1-40, 2004.
[15] J. Wolf, “OMG-WTF-PDF”, en Proc. 27 Caos Comput. Congr., Dic
de 2010.
[16] NA Danielsson, “combinadores totales analizador”, en Proc. 15a
ACM SIGPLAN ICFP, 2010, pp. 285-296.
[17] A. Koprowski y H. Binsztok, “TRX: Un intérprete analizador
verificado formalmente,” en Proc. Prog. Lang. Syst., LNCS 6012.
2010, pp. 345-365.
[18] T. Ridge, “simple y funcional, el sonido y el análisis completo para
todas las gramáticas libres de contexto”, presentado para su
[22] S. Ginsburg y S. Greibach, “libres de contexto lenguas deterministas”, [55] F. Valeur, D. Mutz, y G. Vigna, “Un enfoque basado en el aprendizaje a
en Proc. 6 de Symp. La conmutación de circuitos Teoría del Diseño la detección de ataques SQL”, en Proc. DIMVA, Jul. De 2005, págs.
Lógico, 1965, pp. 203-220. 123-140.
[23] W. , J. Kannan, y HJ Wang, Cui “descubridor: protocolo automático de [56] GT Buehrer, BW Weide, y PAG Sivilotti, “Uso de la validación árbol
la ingeniería inversa de trazas de red”, en Proc. USENIX Sec. Symp., de análisis sintáctico para prevenir ataques de inyección SQL”, en Proc.
2007. En t. N del software del taller. Ing. Middleware, 2005, pp. 106-113.
[24] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, y T. [57] PAG. Bisht, P. Madhusudan, y VN Venkatakrishnan, “Candid: DY-
Berners-Lee, Protocolo de transferencia de hipertexto: HTTP / 1.1, NAMIC evaluaciones de los candidatos para evitar automáticamente los
Petición de Comentarios: 2616, junio de 1999.. ataques de inyección SQL,” ACM Trans. Inf. Syst. Seguridad, vol. 13,
[25] Instituto de Ciencias de la Información, Protocolo de Internet, Solicitud no. 2, pp. 1-39, 2010.
de comentarios: 791, septiembre de 1981. [58] Z. Su y G. Wassermann, “La esencia de los ataques de inyección de
[26] W. Ali, K. Sultana, y S. Pervez, “Un estudio sobre la extensión de comandos en aplicaciones web”, en Proc. 33 Symp. Programa
programación visual de JavaScript,” Int. J. Comput. Appl., Vol. 17, no. principios. Lang., 2006, pp. 372-382.
1, pp. 13- 19, marzo de 2011. [59] W. GJ Halfond y A. Orso, “La prevención de ataques de inyección SQL
[27] PW Abrahams, “una solución definitiva a la persona que cuelga de utilizando amnesia,” en Proc. 28 Int. Conf. N del software. Eng., 2006,
ALGOL pp. 795- 798.
60 y relacionados con los idiomas,”Commun. ACM, vol. 9, pp. 679- [60] G. Wassermann, C. Gould, Z. Su, y P. Devanbu, “comprobación estática
682, Sep. 1 966. de consultas generadas dinámicamente en aplicaciones de bases de
[28] DE Knuth, “Sobre la traducción de idiomas de izquierda a derecha,” datos,” J. ACM Trans. N del software. Ing. Methodol., Vol. 16, no. 4,
Inform. Control, vol. 8, no. 6, pp. 607-639, 1965. 2007.
[29] HJS Basten, “La facilidad de uso de métodos de detección de la [61] K. Wei, M. Muthuprasanna, y S. Kothari, “Prevención de ataques de
ambigüedad de las gramáticas libres de contexto,” Electrón. Notas inyección SQL en procedimientos almacenados”, en Proc. Aus. N del
Theor. Comput. Sci., Vol. 238, pp. 35-46, octubre de 2009. software. Ing. Conf., 2006, pp. 191-198.
[30] RW Floyd, “Sobre la ambigüedad en idiomas frase estructura,” [62] M. Muthuprasanna, K. Wei, y S. Kothari, “ataques de inyección La
Commun. ACM, vol. 5, p. 526, octubre de 1962. eliminación de SQL: un mecanismo de defensa transparente”, en Proc. 8
[31] CE Shannon, “Una teoría matemática de la comunicación,” Campana de IEEE Int. Symp. Sitio Web Evol., Sep. de 2006, pp. 22-32.
Syst. Tech. J., vol. 27, pp. 379-423, Jul. 1 948. [63] C. Gould, Z. Su, y P. Devanbu, “JDBC corrector: Una herramienta de
[32] W. Schramm, “¿Cómo funciona la comunicación”, en el proceso y análisis estático para aplicaciones de SQL / JDBC,” en Proc. En t. Conf.
efectos de la comunicación. Champaign, IL: Univ. Illinois Press, 1954. Suave. Eng., 2004, pp. 697-698.
[33] DK Berlo, el proceso de comunicación. Concord, CA: Holt, Rinehart y [64] AS Christensen, A. Møller, y MI Schwartzbach, “Análisis preciso de
Winston, 1960. expresiones de cadena”, en Proc. 10ª Int. Anal estática. Symp., 2003, pp.
[34] CAR Hoare, “Una base axiomática de la programación informática,” 1-18.
Comu. ACM, Vol. 12, no. 10, pp. 576-583, 1969. [65] S T. Sun y K. Beznosov, “Montaje posterior de las aplicaciones web
[35] HP Grice, estudios realizados en el Camino de las palabras. Cambridge, existentes con protección dinámica eficaz contra los ataques de
MA: Harvard Univ. Press, 1989. inyección SQL,” Int.
[36] B. Meyer, “Aplicación de dsigna por contrato,” Computer, vol. 25, pp. J. Secure Softw. Ing., Vol. 1, pp. 20-40, enero de 2010.
40-51, octubre de 1 992. [66] W. GJ Halfond y A. Orso, “Amnesia: Análisis y seguimiento para
[37] “CWE-77”, en la enumeración debilidad común. Jul. De 2008. neutralizar los ataques de inyección SQL,” en Proc. ASE 2005,
[38] T. Berners-Lee, R. Fielding, y L. Masinter, RFC 3986, Uniform noviembre de 2005, pp. 174-183.
Resource Identifier (URI): Sintaxis Genérica, Petición de Comentarios: [67] W. Halfond, A. Orso, y P. Manolios, “Uso de adulteración positivo y
3986. de enero de 2005. evaluación de sintaxis-consciente para contrarrestar los ataques de
[39] D. Raggett, A. Le Hors, e I. Jacobs, las formas en los documentos inyección SQL”, en Proc. FSE 2006, noviembre de 2006, pp. 175-185.
HTML, HTML 4.01, Dic de 1999. [68] PY Gibello. (2002). ZQL: Java SQL Analizador [En línea].
[40] L. y S. Carettoni di Paola, HTTP Parámetro contaminación. OWASP Disponible:http://zql.sourceforge.net/
UE Polonia, 2009. [69] K. Kemalis y T. Tzouramanis, “SQL-IDS: Un enfoque basado en la
[41] T. Pietraszek y CV Berghe, “La defensa contra los ataques de inyección especificación para la detección de la inyección SQL”, en Proc. Symp.
a través de la evaluación cadena de contexto-sensible”, en Proc. RAID, Appl. Comput., 2008, pp. 2153-2158.
2005, pp. 124-145. [70] A. Liu, Y. Yuan, D. Wijesekera, y A. Stavrou, “SQLProb: una
[42] W. GJ Halfond, J. Viegas, y A. Orso, “Una clasificación de los ataques y arquitectura basada en proxy- hacia la prevención de ataques de
las contramedidas de inyección sql-”, en Proc. IEEE Int. Symp. N del inyección SQL,” en Proc. ACM Symp. Appl. Comput., 2009, pp. 2054-
software seguro. Eng., Marzo de 2006. 2061.
[43] RIX. (2001, agosto). Escribiendo shellcodes alfanuméricos IA32. [71] National Vulnerability Database, CVE-2006-2313, mayo de 2006.
Phrack [línea On-]. 57 (5). \ [72] National Vulnerability Database, CVE-2006-2314, mayo de 2006.
Disponible:http://www.phrack.com/issues.html?issue=57 & Id = 15 [73] D. Knuth, “semántica de los lenguajes libres de contexto,” Matemáticas.
[44] Nergal. (2001, diciembre). El retorno-en-lib avanzada (c) explota: Syst. Theory, vol. 2, pp. 127-145, 1968.
estudio de caso de personas. Phrack [En línea]. 58 (4). [74] B. Kaliski. (1998, marzo). PKCS # 1: RSA Encryption [En línea].
Disponible:http://www.phrack.com/ issues.html? tema = 58 & id = 4 Disponible:http://tools.ietf.org/html/rfc2313
[45] R. Roemer, E. Buchanan, H. Shacham, y S. Savage, “Retorno de [75] B. Ford, “Analizar las gramáticas de expresión: Una base sintáctica
programación orientado a: sistemas, lenguajes y aplicaciones”, que se basada en el reconocimiento”, en Proc. 31 ACM SIGPLAN-SIGACT
publicarán. Symp. POPL, 2004 pp. 111-122.
[46] H. Shacham, “La geometría de carne inocente en el hueso: libc Return- [76] M. Howard, J. Pincus, y J. Wing, “Medición de superficies de ataque
en- sin función llama (en el x86),” en Proc. CCS, 2007. relativos,” en la seguridad informática en el siglo 21, DT Lee, SP Shieh,
[47] T. Durden. (2002, Jul.). Sin pasar por la protección ASLR personas. y
Phrack [En línea]. 59 (9). JD Tygar, Eds. Nueva York: Springer, 2005, pp 109-137..
\
Disponible:http://www.phrack.com/issues.html?issue= 59 & id = 9 [77] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, y W. Polk,
[48] Una. (1996, agosto). Rompiendo la pila para la diversión y el beneficio. certificado de infraestructura de Internet X.509 de la clave pública y la
Phrack [En línea]. 49 (14). lista de revocación de certificados (CRL) Perfil, RFC 5280, RFC 3280
\
Disponible:http://www.phrack.com/issues.html?issue= 49 & id = 14 obsoletes, 4325 , 4630, mayo de 2008.
[49] MaXX. Trucos malloc Vudo. Phrack [En línea]. 57 (8). [78] PAG. Eckersley, “¿Cómo único es su navegador web ?,” Electronic
Disponible:http://phrack.org/issues.html?issue=57&id=8 Frontier Foundation, Tech. Rep., 2009.
[50] autor anónimo. Erase una libre (). Phrack [En línea]. 57 (9). [79] N. Mathewson y R. Dingledine, “análisis de tráfico práctica:
Disponible:http://phrack.org/issues.html?issue=57&id=9 Ampliación y resistir divulgación estadística”, en Proc. Taller de PET,
[51] jp. (2003, agosto). exploits malloc de avanzada Doug Lea. Phrack [línea LNCS 3424. mayo de 2004, págs. 17-34.
On-]. 61 (6). Disponible:http://www.phrack.com/issues.html?issue=61 \ [80] R. Clayton, “Los fallos en un sistema de bloqueo de contenido híbrido”,
& Id = 6 en Proc. Quinto Taller de PET, 2005, p. 1.
[52] T. Newsham. (2000, Sep.). Los ataques formato de cadena [online]. [81] F. Lindner, “El efecto observador comprometida,” McAfee Security J.,
~
Disponible:http://www.thenewsh.com/ newsham / serie-formato- vol. 6, 2010.
attacks.pdf [82] T. Ptacek, T. Newsham, y HJ Simpson, “Inserción, la evasión, y Nial de-
[53] National Vulnerability Database, CVE-2005-3962, Dic de 2005. de servicio: Eludiendo detección de intrusiones en la red,” Secure
[54] National Vulnerability Database, CVE-2011-1153, marzo de 2011. Networks, Inc., de West Palm Beach, FL, Tech. Rep., 1998.
[83] O. Arkin, “el uso de ICMP en la exploración, el know-how completo,”
Grupo de Seguridad Sys, Tech. Rep., Versión 3.0, 2001.
[84] M Handley, V. Paxson, y C. Kreibich, “detección de intrusiones de red: Len Sassaman fue miembro del Grupo de Investigación COSIC, Universidad
Evasión, normalización de tráfico, y la semántica de protocolo de Católica de Lovaina, Bélgica. Sus primeros trabajos con cypherpunks en el
extremo a extremo”, en Proc. 10 de USENIX de Seguridad Symp., sistema despachador Mixmaster anónima y el Proyecto Tor ayudó a establecer
2001, p. 9. el campo de la investigación anonimato. En 2009, él y ML Patterson comenzó
[85] U. Shankar y V. Paxson, “asignación de Active: Resistencia NIDS la formalización de las bases de la seguridad del lenguaje teórico, que se vio
evasión sin alterar el tráfico”, en Proc. IEEE Symp. Privacidad, mayo de involucrado con hasta el final de su vida.
2003, págs. 44-61. El Dr. Sassaman falleció en julio de 2011. Tenía 31 años de edad.
[86] S. Siddharth. (2005, diciembre). NIDS que evaden, Revisited [En línea].
Disponible:http://www.symantec.com/connect/articles/evading-nids-
revisited
[87] T. Garfinkel, “Trampas y escollos: problemas prácticos de las Meredith L. Patterson vive en Bruselas, Bélgica.
herramientas de seguridad basadas en la llamada al sistema de Como Ph.D. estudiante, desarrolló la primera defensa contra el lenguaje de
interposición”, en Proc. Netw. Syst distribuida. Symp seguridad., Feb. la teoría de inyección SQL en 2005 y ha continuado la expansión de la técnica
de 2003, pp. 163-176. desde entonces. En la actualidad con Nuance Communications de Burlington,
[88] SA Hofmeyr, A. Somayaji, y S. Forrest, “intrusión sistema de detección MA, EE.UU.. Es fundadora de honrados hackers LLC, Cheyenne, WY,
utilizando secuencias de llamadas al sistema,” J. Comput. Seguridad, EE.UU..
vol. 6, no. 3, pp. 151-180, 1998.
[89] HH Feng, O. Kolesnikov, P. Fogla, W. Lee, y W. Gong, “La detección
de anomalías utilizando la información de pila de llamadas”, en Proc. Sergey Bratus recibió el Ph.D. grado en matemáticas de la Universidad de
IEEE Symp. Privacidad, mayo de 2003, p. 62. Northeastern, Boston, MA.
[90] D. Wagner y P. Soto, “ataques mimetismo en sistemas de detección de En la actualidad es Profesor Asistente de Investigación de la informática
intrusión basado en host”, en Proc. ACM Conf. CCS, noviembre de con el Dartmouth College, Hanover, Nueva Hampshire. Él ve la piratería del
2002, pp. 255-264. estado de la técnica como una disciplina distinta de investigación e ingeniería
[91] C. Taylor y C. Gates, “desafiante el paradigma de detección de que, aunque todavía no reconocido como tal, alberga una visión profunda de
anomalías: Una discusión provocativa,” en Proc. 15a NSPW, Sep. de la naturaleza de la computación. Estaba con BBN Technologies, Cambridge,
2006, pp. 21-29. MA, trabajando en la investigación de procesamiento de lenguaje natural
[92] R. Sommer y V. Paxson, “Fuera del mundo cerrado: Sobre el uso de la antes de llegar a la universidad de Dartmouth.
máquina de aprendizaje para la detección de intrusiones de red”, en
Proc. IEEE Symp. Privacidad, mayo de 2010, pp. 305-316.
[93] A. Somayaji, S. Hofmeyer, y S. Forrest, “Principios de un sistema
inmune computadora”, en Proc. NPSW, 1998, pp. 75-82. Michael E. Locasto recibió la licenciatura licenciado en ciencias de la
[94] A. Somayaji y S. Forrest, “respuesta automática usando los retrasos de computación (Magna Cum Laude) de la Universidad de Nueva Jersey, Ewing,
llamadas al sistema”, en Proc. 9 de USENIX de Seguridad Symp., y el M.Sc. y Ph.D. títulos de la Universidad de Columbia, Nueva York.
Agosto de de 2000. En la actualidad es profesor adjunto en el Departamento de Ciencias de la
[95] F. B. Schneider, “las políticas de seguridad aplicables,” ACM Trans. Inf. Computación de la Universidad de Calgary, Calgary, AB, Canadá. Se trata de
Syst. Secur., Vol. 3, pp. 30-50, Feb. de 2000. comprender por qué parece difícil construir sistemas seguros, fiables, y cómo
[96] K. Bhargavan, C. Fournet, y AD Gordon, “verificación modular de podemos mejorar en ella.
código de protocolo de seguridad escribiendo,” SIGPLAN Not., Vol. 45,
2010.
[97] S. Chaki y A. Datta, “Aspier: Un marco automatizado para la
verificación de las implementaciones de protocolo de seguridad”, en
Proc. CSF, 2009, pp. 172-185.

Lectura03 en Es

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Lectura03 en Es

Загружено:

Авторское право:

Доступные форматы

IEEE Systems Journal, vol. 7, NO.

Aplicaciones de Seguridad de la Teoría lenguaje

A. Estructura de este documento

II. ¿Por qué las necesidades de seguridad Teoría

III. Formalismos fondo

Fig. 1. jerarquía Chomsky de idiomas de acuerdo con su fuerza expresiva.

que aceptan la entrada en términos de fuerza de la máquina,

3Comparar con el partido decisivo, una máquina de Turing que acepta

B. Modelado de la comunicación desde una perspectiva de

IV. Hazañas como Computación inesperado

A. Los ataques de inyección

B. Otras áreas de ataque

6Su y Wassermann [58] llegaron independientemente en la misma

A. Los ataques de inyección y Validación Analizar árbol libre

5La técnica fue descubierta independientemente por varios equipos de

investigación. Referencias [55] y [56] publicaron enfoques similares en todo

B. Analizar árbol Validación En el contexto-sensible Idiomas

DIGEST-codificación es una cadena ∈ {} fija 0, 1 como se

7) Si en q0 Estado y la cabeza de la cinta está en el para n arbitraria:

(ASN.1) :: = (Digest-Algo) (Hash) La respuesta de destino a( (METRO)) incluye cálculos que

VI. Analizar árbol de análisis diferencial

A. Descubrimiento superficie de ataque

B. Otras aplicaciones de Parse árbol Diferenciales

VII. ¿Por qué Johnny no puede detectar

herramientas como Nmap, Xprobe y hping2 (por ejemplo, Forrest, Somayaji

et al. [88], [93], [94]. Este envase de seguimiento del trabajo

Вам также может понравиться