meta user
network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 1 year, 9 months |
| seen | Apr 23 at 15:39 | |
| stats | profile views | 4 |
|
Oct 18 |
comment |
Can someone detect the URL an android app uses? This is not possible. The data which is shipped and used by your application cannot be made secret to the owner of the device (it can be obfuscated but you will be able to find it by dumping the memory of the device). If your application needs this to be secret for security then your design is broken. |
|
Aug 24 |
awarded | Teacher |
|
Aug 24 |
answered | How to safely view a malicious PDF? |
|
Jul 27 |
awarded | Commentator |
|
Jul 27 |
comment |
What risks do Cookieless sessions have? What are the mitigations? +1 for session fixation. Altough you can do cokkie-based session fixation by using MITM to inject a cookie. How reliable is the use of TLS session ID for sessio tracking. Are there some sites using this method? |
|
Jul 22 |
awarded | Student |
|
Jul 20 |
awarded | Scholar |
|
Jul 20 |
accepted | MITM session injection/invalidation |
|
Jul 19 |
comment |
Does the practice of blocking an off-site “Referer:” HTTP requests improve website security? The "prevent deep linking/bookmarking" point is moot if the Referer header check is done only for actions (POSTs). |
|
Jul 19 |
revised |
MITM session injection/invalidation added 206 characters in body |
|
Jul 19 |
comment |
MITM session injection/invalidation In the article you mention, what I'm describing is not really a login CSRf, but it's another form of "Authenticated as Attacker" attack using cookie overwriting. |
|
Jul 19 |
revised |
MITM session injection/invalidation added 192 characters in body |
|
Jul 19 |
revised |
MITM session injection/invalidation added 192 characters in body |
|
Jul 19 |
comment |
MITM session injection/invalidation Indeed adding a modified Cookie management would prevent this vulnerability. Some kind of per origin cookie space would be a quite useful for security. |
|
Jul 19 |
comment |
MITM session injection/invalidation As I don't expect my username to change without notice, I don't check it on any page (I don't check it at all). I doubt anybody does that … |
|
Jul 19 |
revised |
MITM session injection/invalidation added 143 characters in body |
|
Jul 19 |
revised |
MITM session injection/invalidation added 143 characters in body |
|
Jul 19 |
revised |
MITM session injection/invalidation added 66 characters in body |
|
Jul 19 |
comment |
MITM session injection/invalidation "to be secure sites should be full HTTPS only or not at all". Indeed but in this attack, the plain non-SSL enabled website might not even exist at all. Not having a plain HTTP website is not enough, you have to prevent the browser from trying to access the (non-existant) plain HTTP website using HSTS. |
|
Jul 19 |
comment |
MITM session injection/invalidation Yes but it's slightly different from the more simple CSRF attack where the attacker triggers a login form on exampe.com: this attack can be avoided by validating a form hidden field against a user session cookie (as any other CSRF attack). In this case, as the attacker pushes the session ID, the application can't do much to prevent the attack: the classical CSRF protections won't work against this kind of attack. |
