Category:Access Control - Revision history

Jmanico at 23:37, 1 June 2016

2016-06-01T23:37:16Z

Jmanico: /* Principle of least privilege */

2016-06-01T23:36:17Z

‎Principle of least privilege

Jmanico: /* Principle of least privilege */

2016-06-01T23:36:00Z

‎Principle of least privilege

Jmanico: /* Overview */

2016-06-01T23:32:45Z

‎Overview

Jmanico: /* Definition */

2016-06-01T23:32:33Z

‎Definition

Jmanico: /* Introduction */

2016-06-01T23:32:05Z

‎Introduction

Jmanico: /* Introduction */

2016-06-01T23:31:53Z

‎Introduction

Jmanico at 22:30, 26 February 2016

2016-02-26T22:30:28Z

Jmanico at 22:28, 26 February 2016

2016-02-26T22:28:32Z

Jmanico at 22:27, 26 February 2016

2016-02-26T22:27:26Z

@@ Line 84: / Line 84: @@
 * Dynamic reconfiguration of user interfaces based on authorization;
 * Restriction of access after a certain time of day.
 == Related resources: ==
 # OWASP [[Access Control Cheat Sheet]]

@@ Line 11: / Line 11: @@
 Access control and Authorization mean the same thing. Access control governs decisions and processes of determining, documenting and managing the subjects (users, devices or processes) that should be granted access and the objects to which they should be granted access; essentially, what is allowed. Access controls also govern the methods and conditions of enforcement by which subjects (users, devices or processes) are allowed to or restricted from connecting with, viewing, consuming, entering into or making use of identified information resources (objects).
-== Principle of least privilege ==
+== Principle of Least Privilege ==
 In security, the Principle of Least Privilege encourages system designers and implementers to allow running code only the permissions needed to complete the required tasks and no more. When designing web applications, the capabilities attached to running code should be limited in this manner. This spans the configuration of the web and application servers through the business capabilities of business logic components.

← Older revision		Revision as of 23:36, 1 June 2016
Line 22:		Line 22:

	Finally, the business logic of web applications must be written with authorization controls in mind. Once a user has authenticated to the running system, their access to resources should be limited based on their identity and roles. In addition, users’ attempts to perform actions should also be authorized. Both the J2EE and ASP.NET web application platforms provide the ability to declaratively limit a user’s access to web resources by their identity and roles (as configured in web.xml and web.config respectively). The J2EE platform provides controls down to the method-level for limiting user access to the capabilities of EJB components. By designing file resource layouts and components APIs with authorization in mind, these powerful capabilities of the J2EE and .NET platforms can be used to enhance security.		Finally, the business logic of web applications must be written with authorization controls in mind. Once a user has authenticated to the running system, their access to resources should be limited based on their identity and roles. In addition, users’ attempts to perform actions should also be authorized. Both the J2EE and ASP.NET web application platforms provide the ability to declaratively limit a user’s access to web resources by their identity and roles (as configured in web.xml and web.config respectively). The J2EE platform provides controls down to the method-level for limiting user access to the capabilities of EJB components. By designing file resource layouts and components APIs with authorization in mind, these powerful capabilities of the J2EE and .NET platforms can be used to enhance security.
		+
		+	== Centralized Authorization Routines ==
		+
		+	A common mistake is to perform an authorization check by cutting and pasting an authorization code snippet into every page containing sensitive information. Worse yet would be re-writing this code for every page. Well written applications centralize access control routines, so if any bugs are found, they can be fixed once and the results apply throughout the application immediately.
		+
		+	== Controlling Access to Protected Resources ==
		+
		+	Some applications check to see if a user is able to undertake a particular action, but then do not check if access to all resources required to complete the requested action is allowed. For example, forum software may check to see if a user is allowed to reply to a previous message, but then fails to check that the requested message is not within a protected or hidden forum or thread. Another example would be an Internet Banking application that checks to see if a user is allowed to transfer money, but does not validate that the “from account” is one of the user’s accounts.

	== Some Generic Types of Access Controls: ==		== Some Generic Types of Access Controls: ==

← Older revision		Revision as of 23:32, 1 June 2016
Line 6:		Line 6:

	Often, resources are overlooked when implementing access control systems. For example, buffer overflows are a failure in enforcing write-access on specific areas of memory. Often, a buffer overflow exploit also accesses the CPU in a manner that is implicitly unauthorized as well.		Often, resources are overlooked when implementing access control systems. For example, buffer overflows are a failure in enforcing write-access on specific areas of memory. Often, a buffer overflow exploit also accesses the CPU in a manner that is implicitly unauthorized as well.
		+
		+	== Definition ==
		+
		+	Access control and Authorization mean the same thing. Access control governs decisions and processes of determining, documenting and managing the subjects (users, devices or processes) that should be granted access and the objects to which they should be granted access; essentially, what is allowed. Access controls also govern the methods and conditions of enforcement by which subjects (users, devices or processes) are allowed to or restricted from connecting with, viewing, consuming, entering into or making use of identified information resources (objects).

	== Principle of least privilege ==		== Principle of least privilege ==

← Older revision		Revision as of 23:32, 1 June 2016
Line 18:		Line 18:

	Finally, the business logic of web applications must be written with authorization controls in mind. Once a user has authenticated to the running system, their access to resources should be limited based on their identity and roles. In addition, users’ attempts to perform actions should also be authorized. Both the J2EE and ASP.NET web application platforms provide the ability to declaratively limit a user’s access to web resources by their identity and roles (as configured in web.xml and web.config respectively). The J2EE platform provides controls down to the method-level for limiting user access to the capabilities of EJB components. By designing file resource layouts and components APIs with authorization in mind, these powerful capabilities of the J2EE and .NET platforms can be used to enhance security.		Finally, the business logic of web applications must be written with authorization controls in mind. Once a user has authenticated to the running system, their access to resources should be limited based on their identity and roles. In addition, users’ attempts to perform actions should also be authorized. Both the J2EE and ASP.NET web application platforms provide the ability to declaratively limit a user’s access to web resources by their identity and roles (as configured in web.xml and web.config respectively). The J2EE platform provides controls down to the method-level for limiting user access to the capabilities of EJB components. By designing file resource layouts and components APIs with authorization in mind, these powerful capabilities of the J2EE and .NET platforms can be used to enhance security.
−
−	~~== Definition ==~~
−
−	Access control and Authorization mean the same thing. Access control governs decisions and processes of determining, documenting and managing the subjects (users, devices or processes) that should be granted access and the objects to which they should be granted access; essentially, what is allowed. Access controls also govern the methods and conditions of enforcement by which subjects (users, devices or processes) are allowed to or restricted from connecting with, viewing, consuming, entering into or making use of identified information resources (objects).

	== Some Generic Types of Access Controls: ==		== Some Generic Types of Access Controls: ==

@@ Line 6: / Line 6: @@
 Often, resources are overlooked when implementing access control systems. For example, buffer overflows are a failure in enforcing write-access on specific areas of memory. Often, a buffer overflow exploit also accesses the CPU in a manner that is implicitly unauthorized as well.
 == Introduction ==
 This article focuses on the authorization aspects of access controls as they are reflected in software designs, implementations and the management of software development lifecycles. Some sources include both authentication and authorization as aspects of access control. These are closely related but separate concepts and are managed through different processes.  The granting of authorization is an administrative control.  The enforcement of authorization through software mechanisms is referred to as access control.

← Older revision		Revision as of 22:30, 26 February 2016
Line 125:		Line 125:
	# OWASP [[Access Control Cheat Sheet]]		# OWASP [[Access Control Cheat Sheet]]
	# OWASP [[Guide to Authorization]]		# OWASP [[Guide to Authorization]]
−
−	~~[[Category:Control]]~~
−	~~[[Category:Countermeasure]]~~
−	~~[[Category:Access_Control]]~~

@@ Line 43: / Line 43: @@
 == Access Control Models: ==
 '''Discretionary access controls''' are based on the identity and need-to-know of subjects and/or the groups to which they belong. They are discretionary in the sense that a subject with certain access permissions is capable of passing on that access, directly or indirectly, to other subjects.
 '''Mandatory access controls''' are based on the sensitivity of the information contained in the objects / resources and a formal authorization. They are mandatory in the sense that they restrain subjects from setting security attributes on an object and from passing on their access.
@@ Line 77: / Line 76: @@
 * Restriction of access after a certain time of day.
-== Admin Interfaces ==
+== Administrative Interfaces ==
 Administrative interfaces are one of the few controls which is legally mandated – Sarbanes Oxley requires administrative functions to be segregated from normal functionality as it is a key fraud control. For organizations that have no need to comply with US law, ISO 17799 also strongly suggests that there is segregation of duties.
@@ Line 88: / Line 87: @@
 This is not to say that administrators logging on as users to the primary application are not allowed, but when they do, they should be normal users. An example is a system administrator of a major e-commerce site who also buys or sells using the site.
-==Administrators are not users ==
+=== Administrators are not users ===
 Administrators must be segregated from normal users.
-===How to identify if you are vulnerable ===
+==== How to identify if you are vulnerable ====
 * Log on to the application as an administrator.
 * Can the administrator perform normal transactions or see the normal application?
 * Can users perform administrative tasks or actions if they know the URL of the administration action?
 * Does the administrative interface use the same database or middleware access (for example, database accounts or trusted internal paths?)
 * In a high value system, can users access the system containing the administrative interface?
 If yes to any question, the system is potentially vulnerable.
-===How to protect yourself ===
+==== How to protect yourself ====
 * All systems should have separate applications for administrator and user access.
 * High value systems should separate these systems to separate hosts, which may not be accessible to the wider Internet without access to management networks, such as via the use of a strongly authenticated VPN or from trusted network operations center.
-==Authentication for high value systems ==
+=== Authentication for high value systems ===
 Administrative interfaces by their nature are dangerous to the health of the overall system. Administrative features may include direct SQL queries, loading or backing up the database, directly querying the state of a trusted third party’s system.
-===How to identify if you are vulnerable ===
+==== How to identify if you are vulnerable ====
 If a high value system does not use strong authentication and encrypted channels to log on to the interface, the system may be vulnerable from eavesdropping, man in the middle, and replay attacks.
-===How to protect yourself ===
+==== How to protect yourself ====
 For high value systems:
 * Use a separate hardened management network for administrative access.
 * Use strong authentication to log on, and re-authenticate major or dangerous transactions to prevent administrative phishing and session riding attacks.
 * Use encryption (such as SSL encrypted web pages) to protect the confidentiality and integrity of the session.
 == Related resources: ==