Issue information
-
#024346
-
Fixed
-
3.1.2
-
2.0.0 Beta 3
-
0 - None Assigned
Issue Confirmations
-
Yes (0)No (0)
0
Today I've found this line in server logs:
After shitting some bricks about my server is being hacked, I've made a future investigation and found that the source of problem is OpenID module in IP.Board. It allows spammers to put their referral links into "OpenID URL" field in auth form, and then the server follows this links without any of checking or blacklisting. This situation gives evil people an ability to use IP.Board forums all over the net as their own BotNet to increase visitor counters on their pages or even to DDoS other servers.
Need some kind of blacklisting and whitelisting in OpenID module for the safe of humanity.
[Fri Jul 23 18:27:55 2010] [error] Successfully fetched 'http://adultfriendfinder.com/.....evil_ref_link....': GET response code 200
After shitting some bricks about my server is being hacked, I've made a future investigation and found that the source of problem is OpenID module in IP.Board. It allows spammers to put their referral links into "OpenID URL" field in auth form, and then the server follows this links without any of checking or blacklisting. This situation gives evil people an ability to use IP.Board forums all over the net as their own BotNet to increase visitor counters on their pages or even to DDoS other servers.
Need some kind of blacklisting and whitelisting in OpenID module for the safe of humanity.
Updating status to: Not a Bug
This is the same functionality at every single OpenID provider on the internet. It's how OpenID works effectively. You enter a URL, the server tries to fetch a certain request off of that URL to confirm it's a valid OpenID provider, and if so it sends you there.
I don't think blacklisting or whitelisting is going to be an effective tool for OpenID urls. If this is an issue for you, you could of course disable the OpenID module in IP.Board under Log In Management.
Unless I'm misunderstanding something here, I don't really see what the issue is. Someone put a spam link in the OpenID url. IP.Board would try to fetch it, say "it's not a valid OpenID" and that would be that. If it increases their counters or something, so be it...
This is the same functionality at every single OpenID provider on the internet. It's how OpenID works effectively. You enter a URL, the server tries to fetch a certain request off of that URL to confirm it's a valid OpenID provider, and if so it sends you there.
I don't think blacklisting or whitelisting is going to be an effective tool for OpenID urls. If this is an issue for you, you could of course disable the OpenID module in IP.Board under Log In Management.
Unless I'm misunderstanding something here, I don't really see what the issue is. Someone put a spam link in the OpenID url. IP.Board would try to fetch it, say "it's not a valid OpenID" and that would be that. If it increases their counters or something, so be it...
bfarber, the problem is not in OpenID technology itself, but in auth method. Here is a link, that produces a query to example.com each time you visit it being logged in to forum:
http://community.inv...p://example.com
I can just put in into address bar in my browser and hold down F5, and server will continuously make queries to target domain with no restrictions at all. That is a problem. Also, I can mask this link with a harmless image placed into post body, and that'll be a serious problem with server load and parasite outgoing traffic for you.
http://community.inv...p://example.com
I can just put in into address bar in my browser and hold down F5, and server will continuously make queries to target domain with no restrictions at all. That is a problem. Also, I can mask this link with a harmless image placed into post body, and that'll be a serious problem with server load and parasite outgoing traffic for you.
It's a serious issue, my server was connecting to around 200 sites a day before I finally discovered this problem and pulled the plug. It had been affecting my server's performance somewhat.
I think you should at least put up a message in the ACP, warning admins before they enable it.
A solution could be to place the recaptcha form on the openID login screen.
I think you should at least put up a message in the ACP, warning admins before they enable it.
A solution could be to place the recaptcha form on the openID login screen.
Aoyagi Ritsuka, on 31 July 2010 - 07:31 PM, said:
bfarber, the problem is not in OpenID technology itself, but in auth method. Here is a link, that produces a query to example.com each time you visit it being logged in to forum:
http://community.inv...p://example.com
I can just put in into address bar in my browser and hold down F5, and server will continuously make queries to target domain with no restrictions at all. That is a problem. Also, I can mask this link with a harmless image placed into post body, and that'll be a serious problem with server load and parasite outgoing traffic for you.
http://community.inv...p://example.com
I can just put in into address bar in my browser and hold down F5, and server will continuously make queries to target domain with no restrictions at all. That is a problem. Also, I can mask this link with a harmless image placed into post body, and that'll be a serious problem with server load and parasite outgoing traffic for you.
And if you go to the official OpenID test page (http://test-id.org/OP/Sreg.aspx) and enter in a random URL, it fetches that too. That's how OpenID works.
Mavol, on 01 August 2010 - 03:18 AM, said:
It's a serious issue, my server was connecting to around 200 sites a day before I finally discovered this problem and pulled the plug. It had been affecting my server's performance somewhat.
I think you should at least put up a message in the ACP, warning admins before they enable it.
A solution could be to place the recaptcha form on the openID login screen.
I think you should at least put up a message in the ACP, warning admins before they enable it.
A solution could be to place the recaptcha form on the openID login screen.
It's not an issue, it's working as intended. And absolutely no to adding a captcha. There's absolutely no reason any sane admin would want to place impediments to logging in.
You had secured skin selector form with hidden "k" field, but can't do the same for login form? That's just ridiculous...
That'll be enough to stop the most of automated bots.
That'll be enough to stop the most of automated bots.
Also we should log out a user after his first login attempt, no matter has he logged in with other account or not. Otherwise there is an ability to brute users passwords, cause number of login attempts is unlimited for already logged in users. Or should just don't show login form for users that are already logged in 
Aoyagi Ritsuka, on 01 August 2010 - 05:13 AM, said:
Also we should log out a user after his first login attempt, no matter has he logged in with other account or not. Otherwise there is an ability to brute users passwords, cause number of login attempts is unlimited for already logged in users. Or should just don't show login form for users that are already logged in
That's a different issue, and should be raised as such.
The main issue is the fact that this link works:
http://community.inv...p://example.com
It happens because login form is unsecured & because the number of login attempts for already logged in users is endless. If you'll fix only the second issue - this link will logout you, so, being placed into signature as image will produce a serious problems to community. If you'll fix only the first - that'll be enough for me,m cause automated brute through secured form is not too easy. If you'll fix both - that'll be brilliant x)
http://community.inv...p://example.com
It happens because login form is unsecured & because the number of login attempts for already logged in users is endless. If you'll fix only the second issue - this link will logout you, so, being placed into signature as image will produce a serious problems to community. If you'll fix only the first - that'll be enough for me,m cause automated brute through secured form is not too easy. If you'll fix both - that'll be brilliant x)
Updating status to: Confirmed - General
Ok, let's research this a bit then.
What you are proposing, then, is to add the 'k' variable (or similar) to the login form to prevent the OpenID request from initiating unless it's a valid form submission?
Ok, let's research this a bit then.
What you are proposing, then, is to add the 'k' variable (or similar) to the login form to prevent the OpenID request from initiating unless it's a valid form submission?
Updating severity to: 3 - Medium
Bumping severity since I got some other tickets about this in T2, I would like to have this included in 3.1.3.
Bumping severity since I got some other tickets about this in T2, I would like to have this included in 3.1.3.
Updating status to: Fixed
Updating version to: 3.1.2
Issue fixed in: 3.1.3
I have added a key to the login forms. This means that anyone who has their own login forms will also need to add the key to theirs (i.e. I've seen a dhtml pull down login form modification which would need to have the key added to it).
Updating version to: 3.1.2
Issue fixed in: 3.1.3
I have added a key to the login forms. This means that anyone who has their own login forms will also need to add the key to theirs (i.e. I've seen a dhtml pull down login form modification which would need to have the key added to it).
0 user(s) are reading this issue
0 members, 0 guests, 0 anonymous users
