OWASP - User contributions [en]

User:Allison Nixon

2010-03-13T03:22:54Z

Allison Nixon:

I'm joining this website because it seems like an interesting thing to do.

Allowing Domains or Accounts to Expire

2010-03-13T02:51:57Z

Allison Nixon: Created page with '{{Template:Vulnerability}} Last revision (03/12/10): '''{{MAR}}/{{12}}/{{2010}}''' Vulnerabilities Table of Contents ==Description== Through negle…'

{{Template:Vulnerability}}
Last revision (03/12/10): '''{{MAR}}/{{12}}/{{2010}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

Through neglect an administrator may allow a domain name or e-mail account to expire. Domains have a significant grace period for expiration, and e-mail addresses using free services such as Yahoo may expire after several months of not logging in.

==Risk Factors==

* The biggest risk involved is if you have an e-mail server on a domain that is allowed to expire. The more users there are, the more personal information you are putting at risk when they use those e-mails as backup e-mails for accounts on websites. An attacker can simply purchase the domain and setup a mailserver. By analyzing the spam coming in, they can determine the actual usernames people used on the domain and possibly what services they used with those e-mails.
* Considering that, you should be careful only to use e-mails hosted on domains owned by companies that don't show any sign of going under in the future.
* There is very little recourse if a malicious entity has purchased your domain. They can sell it back to you for however much money they want to charge. Even if you have grounds for a lawsuit, it can take months at least.
* If you have applications(especially no-longer supported) sending data to a domain, if an attacker buys the domain they can gather personal information from your users.
* Domains most likely to expire are those belonging to projects or companies that no longer exist.

Multiple admin levels

2010-02-27T20:20:11Z

Allison Nixon: Created page with ' {{Template:Vulnerability}} Last revision (02/27/10): '''{{FEB}}/{{27}}/{{2010}}''' Vulnerabilities Table of Contents ==Description== In an applic…'

{{Template:Vulnerability}}
Last revision (02/27/10): '''{{FEB}}/{{27}}/{{2010}}'''

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==

In an application with administrators that have the ability to alter login credentials of users, if there are multiple levels of administrator permissions, there needs to be a control preventing administrators with lower permission levels from altering login credentials of higher level admins.

==Risk Factors==

* Likelihood of this happening relies on an attacker getting control of a lower level admin account in the first place.
* Administrator misconduct or mistakes could be made worse if they could easily escalate their own permissions.
* There is no point to create administrators with different levels of permissions if you don't prevent them from easily escalating their own permissions.