The DMZ

« first day (3687 days earlier) ← previous day next day → last day (1185 days later) »

4:09 AM

Random malware tip of the day: encode your C2 and other settings as commented lines in existing configuration files. Much safer than creating your own (even if obfuscated) config.

2 hours later…

nobody

6:25 AM

@forest Reread the question and yes you're right. But then the title doesn't match the question. Anyways retracted my close vote.

3 hours later…

A. Hersean

9:22 AM

@nobody I only listed those for Android

nobody

Oh I see

5 hours later…

MechMK1

2:04 PM

Q: Is this test enough to proof that the web application is vulnerable to Login CSRF?

SCENARIO: web application which I think is affected by: a self-xss in the profile section of a user. logout CSRF login CSRF Below I described the test I did to check for the last 2 vulnerabilities, I'd appreciate an opinion about their correctness. TEST: Logout CSRF: in one tab I'm an authenti...

What exactly is the point of having a "Login CSRF"?

Conor Mancone

@MechMK1 There isn't. There is barely a point to logout CSRF. Login is naturally immune to CSRF

I'll add an answer real quick just because...

I think this is the shortest answer I've ever written

A: Is this test enough to proof that the web application is vulnerable to Login CSRF?

There is no such thing as Login CSRF. Even if your proposed attack causes a login, there is still no such thing as a login CSRF because performing this requires the attacker to know the credentials of the target. At that point in time the attacker would just login as the victim. Q.E.D.

MechMK1

Well, he mentioned a self-XSS

But that barely gives him anything extra

Conor Mancone

2:19 PM

@MechMK1 I decided to just stick to the question in the title. I did add a comment on the question about self-XSS typically not being of interest. I don't even know how you would stop self-XSS

MechMK1

There are 2 ways of self-XSS

The first is a stored XSS on a site that only the person in question can visit

E.g. your profile page if people can only look at their own profile

These are generally harmless

But you don't know how requirements will change. It could be than in a week, management decides admins should be able to view people's profiles

Suddenly you have a nice stored XSS vector

But the self-XSS itself is harmless

The second one is self-XSS via browser console

The idea is using social engineering to get the victim to copy malicious, often obfuscated, javascript code and paste it into their console

Usually this is done by convincing them that this code would unlock some feature, bypass some restriction, or so some other 1337 thing

"Paste this code here to become admin on any discord server"

Conor Mancone

@MechMK1 That's what I was mainly talking about. There isn't really anything that can be done at the application level to stop someone from doing that (other than Facebook and their "DO NOT PASTE CODE HERE" message in the console, but that won't stop someone who is sufficiently gullible)

@MechMK1 Mentally I'd categorize that as a low-impact stored XSS (rather than self-XSS), but there is obviously plenty of wiggle room there. I'd submit something like that to a bug bounty program, although I suspect that many businesses would choose to ignore it (which would be a poor choice)

MechMK1

2:35 PM

@ConorMancone Discord does a reasonably good job