Vbscipt en ASP (o JavaScript, da lo mismo)

Jorge:
Te doy mi punto de vista para que trates de entender porque necesito
esto.

1) Si existe una forma de "conectarse a algo", deberia existir la
contrapartida, o sea, desconectarse de ese algo. Es algo que los usuarios ya
tienen asimilado, y se sienten mas seguro al saber que pueden desconectarse
de algo a lo que estaban conectado. Mas aun si se trata de Windows.Trata de
entender mi situacion. Con tantos bugs, agujeros y fallas que posee Windows
y que se descubren a diario, al usuario solo lo podes tener conforme
vendiendole algo medianamente "seguro". Si ademas de todos los problemas de
seguridad que posee Windows "by design" le sumamos estos detalles, se
complica mucho poder vender algo.

2) Lo que me decis de desconectarse por medio de session.abandon no es asi.
Una cosa es abandonar la sesion actual de asp y otra cosa desconectarse de
la autenticacion que hiciste en windows, por estar en otro dominio, que es
mi caso. Si fuera asi de sencillo, no tendrias una pagina de Microsoft
explicandote como hacer una OCX que permite desconectarte de la
autenticacion hecha. Si tenes dudas, te invito a que pruebes. Luego de hacer
un session.abandon, sin cerrar el explorador, haces F5 y se refresca la
pagina sin pedirte usuario y contraseña del dominio. Si cierras el internet
explorer y te conectas desde otra ventana si te lo pregunta, pero lo hace
siempre, mas alla si hiciste session.abandon o no.

Entiendo y comparto tu punto de vista cuando dices que una persona puede
conectarse a otro dominio desde una aplicacion web lo puede hacer tambien
desde el explorador de windows. Pero lo que quiero dejar en claro al
usuario/cliente es que si alguien utiliza indebidamente el usuario y
contraseña proporcionado para entrar al dominio no es culpa de la aplicacion
que yo le vendo, sino de la persona a quien se le brindan los datos, que no
sabe manejarse con seguridad. Es muy distinto que alguien entre a una PC
desde el explorador de windows, porque pude acceder de alguna manera a
obtener el usuario y contraseña que lo termine haciendo desde mi aplicacion,
por no haber hecho un LOGOUT. Se entiende? Con una pequeña cosa, me desligo
de responsabilidades que no me corresponden. Y me podrias decir ¿ y que pasa
si el usuario desde mi aplicacion no hace logout, por mas que la posibilidd
exista? Y te dire lo mismo: es responsabilidad del usuario manejarse con la
seguridad correspondiente. Si la aplicacion posee todos los medios para
manejarse en forma segura, no puede hacerme responsable de culpas de
terceros. Solo por eso necesito algo asi. Para hacer las cosas bien, como
corresponden y para no ser uno mas del monton que hace las cosas "a medias".
Saludos,

Sebastian E. Garcia

"Jorge Oblitas" escribió en el mensaje
news:
Mostrar la cita

Mientras me respondes adelanto algo ... en base a conjeturas

Asumo que preocupado por la seguridad quieres desloguear a ese usuario
porque lo has logueado a otro dominio NT ... creo que esta preocupacion

es
Mostrar la cita

no es clara por las razones que te dare mas adelante, por el momento te
contare algo, y si me quivocpo, se que alguien de MS o un experto en IIS

me
Mostrar la cita

corregira.

Cuando te autenticas via WINDOWS, tu sesion se amarra al usuario windows

(el
Mostrar la cita

el famoso token que IIS le pasa a ASP)... bien, si cierras su sesion con

un
Mostrar la cita

simple Session.abandon() en un boton logout, la sesion termina, y si
termina, tambien termina la "autenticada" por llamarla de alguna manera.

Eso
Mostrar la cita

lo puedes comprobar pues despues de un session.abandon() habria que
reautenticar al usuario para que se loguee... eso es todo lo que hay que
hacer

pero pro que digo que no es clara? por estas dudas:

CASO 1: el sitio tiene autenticacion windows NT y el usuario es un uusario
del dominio... si el usuario es un usuario del dominio y esta logueado a

el
Mostrar la cita

desde windows, la aplicacion web lo asume de frente, es decir, ni le

pedira
Mostrar la cita

loguearse. En este caso de nada sirve que quieras desloguearlo del dominio
desde la aplicacion porque el se logueo desde antes, al ingresar a

awindows
Mostrar la cita

CASO 2: sitio tiene autenticacion windows NT y el usuario se loguea en

otro
Mostrar la cita

dominio poara trabajar en sus cosas, pero para acceder a la aplicacion

debe
Mostrar la cita

loguearse en otro dominio... en este caso si le pide contraseña... pero si
el suuario tiene contraeña para ingresar a ese dominio, lo podra seguir
haciendo con o sin la aplicacion porque es un usuario de ese dominio desde
ya!!! asi que via el explorador de windows o lo que sea puede acceder a

ese
Mostrar la cita

dominio de acuerdo a los privilegios que su usuario tenga...

Ves?

Jorge



"Sebastian E. Garcia" escribió en el mensaje
news:#
> Si, se entiende. Y buscando ejemplos las respuestas son unanimes con ese
> problema: VBSCRIPT desde asp no soporta dichos llamados por una

cuestion -
Mostrar la cita

> logica - de seguridad. Ahora lo que yo dejo planteado es lo siguiente:
Para
> brindarle "MAYOR" seguridad a una aplicacion Web (asp) decidimos loguear
el
> usuario a un Dominio NT por medio de Autenticacion de Windows Integrada,
sin
> usuario Anonimous. Perfecto! La aplicacion parece segura pq estamos

usando
Mostrar la cita

> Windows NT para manejar seguridad, algo que mas alla de algunos bugs, se
> puede usar para defender y vender una aplicacion. Ahora digo yo, a mitad
de
> mi proyecto, ¿como hago para desconectarme desde ese Dominio desde el
> mismisimo ASP? Debe ser algo sencillo, pienso para mi mismo. Pero

resulta
Mostrar la cita

> ser que, despues de mucho buscar, la unica forma de lograr eso es por
medio
> de un archivo OCX/DLL que el cliente debe DESCARGAR a su PC para poder
> ejecutarlo. Una verdadera locura pedirle a un usuario con permisos
limitados
> que haga eso. Otra locura darle esos permisos porque puede terminar
haciendo
> cualquier cosa. Asi que me encuentro en una paradoja: para darle mayor
> seguridad a una aplicacion WEB debo darle menos seguridad a la PC del
> usuario o al reves...para darle o mantener la seguridad de la pc del
> cliente, debo dejar de usar la autenticacion de windows y pasar a

validad
Mostrar la cita

> contra una base de datos u otra cosa de inferior seguridad. Alguien

puede
Mostrar la cita

> desasnarme o realmente estoy en lo cierto? Si es tan facil loguearse al
> dominio, pq complicarla tanto con el logout? Dios!
> Saludos
>
> Sebastian E. Garcia
>
>
>
> "Gabriel" escribió en el mensaje
> news:O%
> > En vbscript no existe la declaracion implicita de la DLL como en VB.
> >
> > Lo que se hace, es registrar la ocx en la maquina que va a correr la

ocx
Mostrar la cita

> > (con regsvr32) y tan solamente el vbscript hace un:
> > objeto=createobject("nombredelobjetodeclarado en la ocx")
> >
> > OK?
> >
> > Gabriel.
> >
> >
> > "Sebastian E. Garcia" escreveu na mensagem
> > news:
> > > Bueno, luego de mi problema tratando de desconectarme de un dominio

NT
Mostrar la cita

> > > desde
> > > ASP, tengo ahora el inconveniente que el cliente necesita poder

hacer
Mostrar la cita

> > > logout
> > > de la pagina pero sin bajar nada a la PC de los clientes. Cosa casi
> logica
> > > porque a la mayoria de los usuarios en las empresas no se les da
> > > demasiados
> > > permisos por razones de seguridad.
> > > Asi que pensando un poco dije...si el codigo que esta en el archivo
OCX
> es
> > > VisualBasic, y si puedo correr VBSCRIPT del lado del cliente, que me
> > > impide
> > > correr desde VBSCRIPT el mismo codigo que poseo en la OCX? Y el
problema
> > > es
> > > que no puedo correr un PRIVATE DECLARE FUNCTION X IN "ALGUNA.DLL"...
> > > La pregunta es, ¿existe manera de correr el DECLARE desde VBSCRIPT y
que
> > > corra sin problemas? Gracias.
> > >
> > > Sebastian E. Garcia
> > >
> > >
> >
> >
>
>

Sebastian, gracias por tu aclaracion, aunque, como explicare mas adelante,
necesito mas datos.

Para comenzar aqui estamos hablando de uno de una vulnerabilidad de la
seguridad muy critica llamada INGENIERIA SOCIAL... usuarios cuyos password
son el nombre del hijo, el cumpleaños, o que escriben la password en el
escritorio o se la dan a todo el mundo son un problema comun... y las
politicas de educacion en seguridad en las compañias constituyen la mejor
respuesta.

Como te dije en una de mis respuestas, si haces un session.abandon, se
cierra la sesion pero como en mi ejemplo, ya que estas usando autenticacion
windows, cuando haces cualquier otra cosa como refrescar, el servidor
nuevamente le pregunta a windows "quien es este?", porque no te pregunta a
ti... pero lo mas probable es que aun tengas en el cache el hash (recuerdas
el token que mencione) que le dice a la aplicacion quien eres y listo...

Entonces, por que digo lo del explorador de windows y por que insisto en
conocer el problema? por lo siguiente: Si yo tengo un usuairo admitido en
una maquina, usando software que me permita acceder a ella lo suficiente
como para que me pida autenticarme, podre hacerlo... la web es solo una de
las posibles puertas para un usuario autenticado.

Entonces, como no se bien el entorno del problema, asumire que es un usuario
conectandose desd eun cibercafe y quieres asegurarte que no se vaya dejando
todo conectado...

- primer problema: cibercafe: la configuracion de esa maquina en cuanto a
seguridad (lo permitido y lo no permitido) puede ser cualquier cosa... no
podemos entonces asumirla como algo dado a nuestro favor

- segundo problema: No podemos decirle al usuario configure la seguridad
para reciber tu activeX porque si no confias en que haga bien las cosas, no
esperaras configure todo para recibir un activeX... Ademas, sin activex
podrias decirle que apague la PC... pero de seguro lo matan en el cibercfe
por hacer eso...

Entonces el problema esta compuesto por uno de estos casos

1. el usuario se va dejando el browser abierto
2. el usuario se va dejando el browser cerrado ... si es este el caso y el
proceso IEXPLORE.EXE de esa maquina es apagado, entonces el usuario ya no
esta conectado...


claro, aqui viene la cosa... y como matas ese proceso especificamente (me
refiero a que podrias tener mas de un iexplore.exe)... como no sabes
tendrias que cerrar todos los browsers abiertos...Sashka menciono un truco
para hacerlo, no se si funcionara con todos los browsers abiertos, pero al
ir al Parent de seguro cerrara todas las ventanas de ese proceso... OJO que
si haces esto igual debes cerrar la sesion por un problema de seguridad y
performance pues la sesion debe ser terminada si o si.


Opciones

1. Matar el proceso mediante un ActiveX... en este escenario no me parece
practico
2. Cerrar la sesion y las ventanas... esa podria ser una opcion si logras
correr eso... es decir, que el usuario se desloguee a proposito para que el
trigger salte y se haga todo eso.
3. Si no confias en que el usuario haga eso, entonces el trigger peude ser
un tiempo determinado... pero esto siempre da temor... porque hay un lapso
de tiempo en que todo esta vivo aunque el usuario ya no este...

Debido a esto, es que de acuerdo al metodo d ela pregunta correcta yo
volveria a las raices:

La pregunta correcta no es: como cierro el proceso o como "deslogueo" al
usuario. La pregunta correcta es como me aseguro que el usuario que accede
es un usuario verdadero

Entonces surgen opciones de todo calibre para resolver el problema.

1. Autenticacion por formularios contra una base de datos y expiracion
automatica de paginas: En este caso un session abandon mata la sesion y el
cache... pero tal vez aun te de miedo
2. Smart cards o algun tipo de autenticacion... por ejemplo un CD cuyo
codigo es leido por la aplicacion para cada request... pero claro, el
usuario olvida el CD dentro de la PC y adios... bueno, sin exagerar
3. Autenticacion Windows con un usuario que tiene permisos de lectura solo
sobre la carpeta d ela aplicacion... lo que podria ser problema si el
usuario es un usuario de la empresa que disfruta de muchos privilegios de
red... ya que se los quitariamos... Pero diras.. igual es el mismo problema,
yo no quiero que el usuario siga conectado a la apliccion aunque sea solo
para verla. Pues podrias agregar un codigo o algo a la sesion de manera que
SI BIEN EL TOKEN TE AUTENTICA, no te autorice. Es decir, podemos crear
cierta autorizacion como variable de sesion. Si un request no contiene esta
autorizacion, podemos asumir que el usuario no esta autorizado y negarle el
acceso. Solo se crear esta variable de sesion al loguearse y al cerrar la
sesion muere... EL unico problema que se me ocurre es que el mismo usuario
quiera acceder luego del session.abandon y tenga ese problema, es decir,
Windows diciendo este es fulano de tal y la aplicacion negandole el acceso
por no tener el codigo mencionado... en ese caso podrias averiguar como
obligar al usuario a loguearse de neuvo... asi, al recibir un request sin el
codigo en la sesion, realizas la accion que obliga a reautenticarse... o lo
mandas a una pagina en donde le indicas que correr o como cerrar los browser
para loguearse de nuevo

Jorge


AL final todo cae en el usuario y su eduacacion. HACERLO RESPONSABLE DE SUS
ACTOS.
2.




"Sebastian E. Garcia" escribió en el mensaje
news:uhy$
Mostrar la cita

Jorge:
Te doy mi punto de vista para que trates de entender porque

necesito
Mostrar la cita

esto.

1) Si existe una forma de "conectarse a algo", deberia existir la
contrapartida, o sea, desconectarse de ese algo. Es algo que los usuarios

ya
Mostrar la cita

tienen asimilado, y se sienten mas seguro al saber que pueden

desconectarse
Mostrar la cita

de algo a lo que estaban conectado. Mas aun si se trata de Windows.Trata

de
Mostrar la cita

entender mi situacion. Con tantos bugs, agujeros y fallas que posee

Windows
Mostrar la cita

y que se descubren a diario, al usuario solo lo podes tener conforme
vendiendole algo medianamente "seguro". Si ademas de todos los problemas d

e
Mostrar la cita

seguridad que posee Windows "by design" le sumamos estos detalles, se
complica mucho poder vender algo.

2) Lo que me decis de desconectarse por medio de session.abandon no es

asi.
Mostrar la cita

Una cosa es abandonar la sesion actual de asp y otra cosa desconectarse de
la autenticacion que hiciste en windows, por estar en otro dominio, que es
mi caso. Si fuera asi de sencillo, no tendrias una pagina de Microsoft
explicandote como hacer una OCX que permite desconectarte de la
autenticacion hecha. Si tenes dudas, te invito a que pruebes. Luego de

hacer
Mostrar la cita

un session.abandon, sin cerrar el explorador, haces F5 y se refresca la
pagina sin pedirte usuario y contraseña del dominio. Si cierras el

internet
Mostrar la cita

explorer y te conectas desde otra ventana si te lo pregunta, pero lo hace
siempre, mas alla si hiciste session.abandon o no.

Entiendo y comparto tu punto de vista cuando dices que una persona puede
conectarse a otro dominio desde una aplicacion web lo puede hacer tambien
desde el explorador de windows. Pero lo que quiero dejar en claro al
usuario/cliente es que si alguien utiliza indebidamente el usuario y
contraseña proporcionado para entrar al dominio no es culpa de la

aplicacion
Mostrar la cita

que yo le vendo, sino de la persona a quien se le brindan los datos, que

no
Mostrar la cita

sabe manejarse con seguridad. Es muy distinto que alguien entre a una PC
desde el explorador de windows, porque pude acceder de alguna manera a
obtener el usuario y contraseña que lo termine haciendo desde mi

aplicacion,
Mostrar la cita

por no haber hecho un LOGOUT. Se entiende? Con una pequeña cosa, me

desligo
Mostrar la cita

de responsabilidades que no me corresponden. Y me podrias decir ¿ y que

pasa
Mostrar la cita

si el usuario desde mi aplicacion no hace logout, por mas que la

posibilidd
Mostrar la cita

exista? Y te dire lo mismo: es responsabilidad del usuario manejarse con

la
Mostrar la cita

seguridad correspondiente. Si la aplicacion posee todos los medios para
manejarse en forma segura, no puede hacerme responsable de culpas de
terceros. Solo por eso necesito algo asi. Para hacer las cosas bien, como
corresponden y para no ser uno mas del monton que hace las cosas "a

medias".
Mostrar la cita

Saludos,

Sebastian E. Garcia

"Jorge Oblitas" escribió en el mensaje
news:
> Mientras me respondes adelanto algo ... en base a conjeturas
>
> Asumo que preocupado por la seguridad quieres desloguear a ese usuario
> porque lo has logueado a otro dominio NT ... creo que esta preocupacion
es
> no es clara por las razones que te dare mas adelante, por el momento te
> contare algo, y si me quivocpo, se que alguien de MS o un experto en IIS
me
> corregira.
>
> Cuando te autenticas via WINDOWS, tu sesion se amarra al usuario windows
(el
> el famoso token que IIS le pasa a ASP)... bien, si cierras su sesion con
un
> simple Session.abandon() en un boton logout, la sesion termina, y si
> termina, tambien termina la "autenticada" por llamarla de alguna manera.
Eso
> lo puedes comprobar pues despues de un session.abandon() habria que
> reautenticar al usuario para que se loguee... eso es todo lo que hay que
> hacer
>
> pero pro que digo que no es clara? por estas dudas:
>
> CASO 1: el sitio tiene autenticacion windows NT y el usuario es un

uusario
Mostrar la cita

> del dominio... si el usuario es un usuario del dominio y esta logueado a
el
> desde windows, la aplicacion web lo asume de frente, es decir, ni le
pedira
> loguearse. En este caso de nada sirve que quieras desloguearlo del

dominio
Mostrar la cita

> desde la aplicacion porque el se logueo desde antes, al ingresar a
awindows
>
> CASO 2: sitio tiene autenticacion windows NT y el usuario se loguea en
otro
> dominio poara trabajar en sus cosas, pero para acceder a la aplicacion
debe
> loguearse en otro dominio... en este caso si le pide contraseña... pero

si
Mostrar la cita

> el suuario tiene contraeña para ingresar a ese dominio, lo podra seguir
> haciendo con o sin la aplicacion porque es un usuario de ese dominio

desde
Mostrar la cita

> ya!!! asi que via el explorador de windows o lo que sea puede acceder a
ese
> dominio de acuerdo a los privilegios que su usuario tenga...
>
> Ves?
>
> Jorge
>
>
>
> "Sebastian E. Garcia" escribió en el mensaje
> news:#
> > Si, se entiende. Y buscando ejemplos las respuestas son unanimes con

ese
Mostrar la cita

> > problema: VBSCRIPT desde asp no soporta dichos llamados por una
cuestion -
> > logica - de seguridad. Ahora lo que yo dejo planteado es lo siguiente:
> Para
> > brindarle "MAYOR" seguridad a una aplicacion Web (asp) decidimos

loguear
Mostrar la cita

> el
> > usuario a un Dominio NT por medio de Autenticacion de Windows

Integrada,
Mostrar la cita

> sin
> > usuario Anonimous. Perfecto! La aplicacion parece segura pq estamos
usando
> > Windows NT para manejar seguridad, algo que mas alla de algunos bugs,

se
Mostrar la cita

> > puede usar para defender y vender una aplicacion. Ahora digo yo, a

mitad
Mostrar la cita

> de
> > mi proyecto, ¿como hago para desconectarme desde ese Dominio desde el
> > mismisimo ASP? Debe ser algo sencillo, pienso para mi mismo. Pero
resulta
> > ser que, despues de mucho buscar, la unica forma de lograr eso es por
> medio
> > de un archivo OCX/DLL que el cliente debe DESCARGAR a su PC para poder
> > ejecutarlo. Una verdadera locura pedirle a un usuario con permisos
> limitados
> > que haga eso. Otra locura darle esos permisos porque puede terminar
> haciendo
> > cualquier cosa. Asi que me encuentro en una paradoja: para darle mayor
> > seguridad a una aplicacion WEB debo darle menos seguridad a la PC del
> > usuario o al reves...para darle o mantener la seguridad de la pc del
> > cliente, debo dejar de usar la autenticacion de windows y pasar a
validad
> > contra una base de datos u otra cosa de inferior seguridad. Alguien
puede
> > desasnarme o realmente estoy en lo cierto? Si es tan facil loguearse

al
Mostrar la cita

> > dominio, pq complicarla tanto con el logout? Dios!
> > Saludos
> >
> > Sebastian E. Garcia
> >
> >
> >
> > "Gabriel" escribió en el mensaje
> > news:O%
> > > En vbscript no existe la declaracion implicita de la DLL como en VB.
> > >
> > > Lo que se hace, es registrar la ocx en la maquina que va a correr la
ocx
> > > (con regsvr32) y tan solamente el vbscript hace un:
> > > objeto=createobject("nombredelobjetodeclarado en la ocx")
> > >
> > > OK?
> > >
> > > Gabriel.
> > >
> > >
> > > "Sebastian E. Garcia" escreveu na mensagem
> > > news:
> > > > Bueno, luego de mi problema tratando de desconectarme de un

dominio
Mostrar la cita

NT
> > > > desde
> > > > ASP, tengo ahora el inconveniente que el cliente necesita poder
hacer
> > > > logout
> > > > de la pagina pero sin bajar nada a la PC de los clientes. Cosa

casi
Mostrar la cita

> > logica
> > > > porque a la mayoria de los usuarios en las empresas no se les da
> > > > demasiados
> > > > permisos por razones de seguridad.
> > > > Asi que pensando un poco dije...si el codigo que esta en el

archivo
Mostrar la cita

> OCX
> > es
> > > > VisualBasic, y si puedo correr VBSCRIPT del lado del cliente, que

me
Mostrar la cita

> > > > impide
> > > > correr desde VBSCRIPT el mismo codigo que poseo en la OCX? Y el
> problema
> > > > es
> > > > que no puedo correr un PRIVATE DECLARE FUNCTION X IN

"ALGUNA.DLL"...
Mostrar la cita

> > > > La pregunta es, ¿existe manera de correr el DECLARE desde VBSCRIPT

y
Mostrar la cita

> que
> > > > corra sin problemas? Gracias.
> > > >
> > > > Sebastian E. Garcia
> > > >
> > > >
> > >
> > >
> >
> >
>
>