[Javalist] Browser-naplózás

2013. Ápr. 11., Cs, 23:24:33 CEST

Hmmmm,

Content Inspection and Https<http://www.vyatta.org/comment/4633#comment-4633>
The only way to scan for viruses in encrypted traffic is to create a full-proxy, non-transparent in the middle of the communications. SSL is specifically designed to try to reject man-in-the-middle attacks, and virus scanning of sessions would require a (benevolent) man-in-the-middle doing the scanning. In order to achieve this, the client has to know that it's connecting to a proxy who is doing the scanning for it. There are a couple problems with this:
1. The client has to use the proxy. Configuration can be mitigated with autoconf protocols, but there will always be some segmentation of the population that won't use the proxy.
2. An intermediate proxy creates other security issues because the proxy sees all the traffic flowing through it unencrypted. The proxy would essentially have access to all user names, passwords, and private information transferred through the system (online banking, stock trades, etc.).
Az első neked nem játszik, de a második azért komoly problémákat vet fel. Tegyük fel egy alkalmazottnak feltörik az online bankolását, és azt állítja hogy a cégnél lopta el valaki a jelszavát.  Tényleg kell ez neked?

Üdv,
Iván
______________________________
István Ketler
Senior Consultant

Lufthansa Systems Hungária Kft.
GUI Service Center
Mobile Solutions Team, Development Center Danube
Neumann János u. 1/e
1117 Budapest
Hungary
Phone: +36 1 887-2815
Fax: +36 1 887-0577
Mobile: +36 30 600-4936
E-mail: istvan.ketler at LHsystems.com<mailto:istvan.ketler at LHsystems.com>
www.LHsystems.com<http://www.lhsystems.com/>

From: javalist-bounces at lists.javaforum.hu [mailto:javalist-bounces at lists.javaforum.hu] On Behalf Of Komáromi, Zoltán
Sent: Thursday, April 11, 2013 10:44 PM
To: Java lista
Subject: Re: [Javalist] Browser-naplózás

A második tetszik :) de ha nekem kellene megcsinálni, biztosan a proxyban gondolkoznék.

2013. április 11. 21:30 Vig Balázs írta, <balazs.vig at datasolutions.hu<mailto:balazs.vig at datasolutions.hu>>:
Szerintem is a proxy a jó megoldás (de 0-ás verzió lehet az is, hogy a céges tűzfalon letiltjátok az oldal elérését egy gép kivételével, ahol a titkárnő mindig felírja, mit kért le....)

Üdv:
VigB

2013. április 11. 18:43 Zsombor írta, <gzsombor at gmail.com<mailto:gzsombor at gmail.com>>:

Miért esik ki egy http proxy alkalmazása? Squid, de amúgy servletként sem nehéz egy ilyet leprogramozni
2013.04.11. 18<tel:2013.04.11.%2018>:38, "Molnár Miklós" <timortinj at freemail.hu<mailto:timortinj at freemail.hu>> ezt írta:
Sziasztok!

Szeretnék kérni némi szellemi-lelki segítséget ötletek formájában, mert valami – szvsz - agyament feladatot kellene abszolválni.
Az is jó lenne, sikerülne megindokolni, hogy lehet kibújni alóla (bár ez perpillanat mission impossible-nek tűnik).
;)

Adva van két cég aki halálba sz*patja egymást.
Az egyik cég pénzért ad adatokat egy másik cégnek; egy egyébként böngészős rémes frame-es felületen keresztül (természetesen webservice-ről „nem hallottak” eddig még soha)
A dolog úgy néz ki, hogy böngészőben formokat kell kitölteni adatkérés címén (4+ db form 20+ db formmező), majd gomb megnyomása után részben html-ben, részben pdf-ben (böngészőben megnyitva) esnek be a „pénzes” információk.
A kommunikáció https csatornán keresztül történik.
Az egészhez dukál egy jelszóvédett certificate (nem tudja akárki, akármilyen böngésző alá telepíteni)

A pénzt fizető, pénzes információt fogadó cég vezetőinek „élet-halál” kérdés, hogy tehát kliens-oldalon(!), naplózódjék, melyik dolgozója milyen kérést küldött ki a browseren keresztül, a pénzt kaszáló, szervert üzemeltető cég felé.
Magyarán a dolgozói milyen adatokkal töltötték fel a request formokat (az nem érdekli milyen adatokat kapnak a felhasználói)
Természetesen a budget nulla forint, a határidő tegnapra, és persze a létező legegyszerűbb (pl.: tool) megoldás kellene.

Ami nekem eszembejutott a csirke-agyammal:

(1)    Mozilla Firefox. Open Source böngésző teljes forrásban. Úgy módosítom a magam számára, ahogy akarom, ugye. De azt hiszem könnyedén belátható, hogy nem járható út.

(2)    Mozilla Firefox alá keylogger add-on. Sajnos járhatatlan, mert egyetlen stringbe adja vissza ömlesztve az összes form-adatot (tarkítva opcionális backspace-ekkel, of course).
Ember nincs aki, programból parse-olja a keylogger kimenetét.
Ugyanezért nem jó a firewall-watching, vagy akármilyen monitoring eszköz sem.

(3)    Előtét form-képernyő programozása. Ekkor ugyan megvan a kívánt naplózás, igen ám, de egyik gond, hogy mi van, ha változik a túloldal form-felépítése /és erre előre látatlanban lehet mérget venni ;)/, másrészt ugye meg is kell jeleníteni a kapott cuccokkat (html,pdf), a dolgozónak (eredeti funkcionalitásként, a munkavégzéséhez).
És akkor egy szót sem szóltam, hogy a formokba gépelt felhasználói adatokat hogyan illesztem be a szerver-oldal felé menő kérésbe, amit perpillanat egyelőre nem is látok át, hogy tudom megtenni.

Magyarán adatcserénél egyszerre kéne használni a browsert, meg kellene rá „ortogonálisan” egy teljes értékű naplózásos funkcionalitás, kliens-oldalon.
Külön-külön még akár triviális is a probléma. Browseren keresztül megy minden, formkitöltést naplózó progit is könnyű írni.

Na de együtt a kettő?

Köszi minden tippért:
MM

_______________________________________________
Javalist mailing list
Javalist at lists.javaforum.hu<mailto:Javalist at lists.javaforum.hu>
http://lists.javaforum.hu/mailman/listinfo/javalist

_______________________________________________
Javalist mailing list
Javalist at lists.javaforum.hu<mailto:Javalist at lists.javaforum.hu>
http://lists.javaforum.hu/mailman/listinfo/javalist

_______________________________________________
Javalist mailing list
Javalist at lists.javaforum.hu<mailto:Javalist at lists.javaforum.hu>
http://lists.javaforum.hu/mailman/listinfo/javalist

--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20130411/269139bf/attachment.html>