| 1 |
On Saturday 23 Jan 2016 09:55:35 Rich Freeman wrote: |
| 2 |
> On Sat, Jan 23, 2016 at 8:25 AM, Mick <michaelkintzios@×××××.com> wrote: |
| 3 |
> > On Tuesday 19 Jan 2016 15:59:25 Grant wrote: |
| 4 |
> >> > If a user certificate is lost of feared compromised, you revoke it with |
| 5 |
> >> > your CA and upload the CRL to the server. |
| 6 |
> >> > |
| 7 |
> >> > However, this won't do away with XSS, or other similar attack vectors |
| 8 |
> >> > if |
| 9 |
> >> > the users are not careful with their browsing habits. |
| 10 |
> >> |
| 11 |
> >> Can you give me an example? |
| 12 |
> > |
| 13 |
> > If your coder has another website page open in his/her browser which |
| 14 |
> > contains for example XSS or CSRF code, then the webpage of your company's |
| 15 |
> > web app could be potentially compromised by your user inadvertently |
| 16 |
> > executing state changing commands on it. By providing a XSS payload the |
| 17 |
> > attacker could execute commands to change username/passwd, change email |
| 18 |
> > address, etc. This is one reason that Internet Banking providers always |
| 19 |
> > advise their users to log out and then exit their browser when they have |
| 20 |
> > finished their online banking. |
| 21 |
|
| 22 |
> The other obvious attack would be simply stealing your session cookies |
| 23 |
> or SSL client certificate+key out of the browser's RAM, or off of |
| 24 |
> disk. |
| 25 |
|
| 26 |
Yes, session hi/sidejacking is possible, as well as obtaining sensitive |
| 27 |
information that the browser has happened to cache. High value information |
| 28 |
like credit card details should have a no-cache, no-store, Expires:0, but I |
| 29 |
bet there are some websites out there which do not guard against this threat. |
| 30 |
I would have thought SSL certificates/keys would be protected in RAM, but if |
| 31 |
you have a Man-In-The-Browser attack I guess they wouldn't be. |
| 32 |
|
| 33 |
If you are using a VPN connection as a split-tunnel then although your |
| 34 |
connection to the LAN would be secure, browser credentials could still be |
| 35 |
stolen by browser sessions connecting to suspect websites outside the tunnel. |
| 36 |
It has to be a full VPN tunnel with forwarding Internet access blocked at the |
| 37 |
VPN gateway, for clients to mitigate this threat. |
| 38 |
-- |
| 39 |
Regards, |
| 40 |
Mick |
Archives