OWASP Top 10 Security Concerns In 2013"

From Documentation
 
(28 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
#REDIRECT [[ZK_Developer%27s_Reference/Security_Tips/OWASP_Top_10_Security_Concerns_In_2017]]
 
= What is the OWASP Top 10? =
 
= What is the OWASP Top 10? =
  
−
The Open Web Application Security Project (OWASP) is a worldwide not-for-profit charitable organization focused on improving the security of software. The OWASP Top Ten is a powerful awareness document for web application security that provides a list of the 10 most critical web application security risks. The most recent version of this document was published in 2013.
+
The Open Web Application Security Project (OWASP<ref>The Open Web Application Security Project [https://www.owasp.org/index.php/Main_Page official website]</ref>) is a worldwide not-for-profit charitable organization focused on improving the security of software. The OWASP Top 10<ref>The OSWAP Top 10 [https://www.owasp.org/index.php/Top_10_2013 document]</ref> is a powerful awareness document for web application security that presents a list of the 10 most critical web application security risks. The most recent edition of this document was published in 2013.
  
 
= OWASP Top 10 in 2013 =
 
= OWASP Top 10 in 2013 =
  
−
In the subsections that follow, the top 10 security risks are summarized briefly. Interested parties are encouraged to visit OWASP, or other abundant web resources for more information on each security risks. Depending on the nature of security vulnerability, a front-end framework such as ZK is not the source of weaknesses that need to be strengthened. Application developers need to understand the vulnerabilities leading to the possible exploits attackers may choose to target your system. With that knowledge, software authors can take preventative measures to mitigate these threats.
+
In the subsections that follow, we provide our statements against each of the top 10 security risks. Interested parties are encouraged to visit OWASP to see this document in full, or other abundant web resources for more information about each security risk. Depending on the nature of vulnerability, a front-end framework such as ZK is not the source of weaknesses that need to be strengthened. Application developers need to understand the vulnerabilities leading to the possible exploits attackers may choose to target your system. With that knowledge, software authors can take preventative measures to mitigate these threats.
  
−
== Injection ==
+
== [https://www.owasp.org/index.php/Top_10_2013-A1-Injection (A1) Injection] ==
  
−
Injection flaws occur when an application sends untrusted data to an interpreter. For example, if the application uses untrusted data in the construction of a SQL command, then an attacker can send specially designed text strings that exploit the syntax of the SQL language to change the meaning of the original query.
+
ZK has no assumption about any 3rd party technologies, and cannot cover their required escaping syntax. This security risk needs to be addressed during application development where untrusted data were utilized in conjunction with an interpreter. For example, to prevent SQL injection, user data should not be used to construct SQL command directly; instead, parameterized queries should be used.
  
−
ZK has no assumption about any 3rd party technology, and cannot cover their required escaping syntax. This security risk needs to be addressed during application development where untrusted data were utilized in conjunction with an interpreter. For example, to prevent SQL injection, user data should not be used to construct SQL command directly; instead, parameterized queries should be used.
+
== [https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management (A2) Broken Authentication and Session Management] ==
  
−
== Broken Authentication and Session Management ==
+
Since ZK does not provide any login mechanism, it is up to developers to choose and secure user authentication management mechanism on their own.
  
−
Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, password management, timeouts, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique.
+
== [https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS) (A3) Cross-Site Scripting (XSS)] ==
  
−
== Cross-Site Scripting (XSS) ==
+
Please see our [http://books.zkoss.org/wiki/ZK_Developer%27s_Reference/Security_Tips/Cross-site_scripting tips] on how to deal with this security issue in ZK.
  
−
Cross-Site Scripting occurs when an application includes user supplied data in a page sent to the browser without property validating or escaping that content.
+
== [https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References (A4) Insecure Direct Object References] ==
  
−
== Insecure Direct Object References ==
+
In ZK, developers have full control over which objects they want to make available on the client-side. Sensitive information does not require to be exposed to client-side manipulation by leaving it in the desktop or session scope. The indirection occurs through ZK components. The developer decides when to read values from input components, and save them on the server.
  
−
Applications frequently use the actual name or key of an object when generating pages. Applications does not always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. For example, if an application uses request parameter to identity the account, an attacker, who is an authorized system user, can change the parameter value to access another account he is not authorized to access.
+
== [https://www.owasp.org/index.php/Top_10_2013-A5-Security_Misconfiguration (A5) Security Misconfiguration] ==
  
−
== Security Misconfiguration ==
+
Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code. Developers and system administrators need to work together to ensure that the entire stack is configured properly.
 +
 
 +
== [https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure (A6) Sensitive Data Exposure] ==
 +
 
 +
Developers have full control over which data is displayed in a zul page, and must avoid exposing sensitive data.
  
−
Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code. Developers and system administrators need to work together to ensure that the entire stack is configured properly.
+
== [https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control (A7) Missing Function Level Access Control] ==
 +
 
 +
Since ZK is programmed in Java language, developers have full control over the availability of backend service functions.
 +
 
 +
== [https://www.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF) (A8) Cross-Site Request Forgery (CSRF)] ==
 +
 
 +
Please refer to our [http://books.zkoss.org/wiki/ZK_Developer%27s_Reference/Security_Tips/Cross-site_Request_Forgery document] on this topic.
  
−
== Sensitive Data Exposure ==
+
== [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities (A9) Using Components with Known Vulnerabilities] ==
  
−
The most common flaw is simply not encrypting sensitive data. When cryptology is employed, weak key generation and management, and weak algorithm usage is common, particularly weak password hashing techniques.
+
ZK addresses known vulnerabilities at high priority. Once identified, we provide updates and patches as soon as possible. Hence, it is recommended to upgrade to the latest version when it becomes available.
  
−
== Missing Function Level Access Control ==
+
== [https://www.owasp.org/index.php/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards (A10) Unvalidated Redirects and Forwards] ==
  
−
== Cross-Site Request Forgery (CSRF) ==
+
Since ZK is a web application running in a servlet container, the developer has control over forwards/redirects to external URLs.
  
−
== Using Components with Known Vulnerabilities ==
+
= References =
  
−
== Unvalidated Redirects and Forwards ==
+
<references/>

Latest revision as of 06:34, 17 January 2018

Redirect to:

What is the OWASP Top 10?

The Open Web Application Security Project (OWASP[1]) is a worldwide not-for-profit charitable organization focused on improving the security of software. The OWASP Top 10[2] is a powerful awareness document for web application security that presents a list of the 10 most critical web application security risks. The most recent edition of this document was published in 2013.

OWASP Top 10 in 2013

In the subsections that follow, we provide our statements against each of the top 10 security risks. Interested parties are encouraged to visit OWASP to see this document in full, or other abundant web resources for more information about each security risk. Depending on the nature of vulnerability, a front-end framework such as ZK is not the source of weaknesses that need to be strengthened. Application developers need to understand the vulnerabilities leading to the possible exploits attackers may choose to target your system. With that knowledge, software authors can take preventative measures to mitigate these threats.

(A1) Injection

ZK has no assumption about any 3rd party technologies, and cannot cover their required escaping syntax. This security risk needs to be addressed during application development where untrusted data were utilized in conjunction with an interpreter. For example, to prevent SQL injection, user data should not be used to construct SQL command directly; instead, parameterized queries should be used.

(A2) Broken Authentication and Session Management

Since ZK does not provide any login mechanism, it is up to developers to choose and secure user authentication management mechanism on their own.

(A3) Cross-Site Scripting (XSS)

Please see our tips on how to deal with this security issue in ZK.

(A4) Insecure Direct Object References

In ZK, developers have full control over which objects they want to make available on the client-side. Sensitive information does not require to be exposed to client-side manipulation by leaving it in the desktop or session scope. The indirection occurs through ZK components. The developer decides when to read values from input components, and save them on the server.

(A5) Security Misconfiguration

Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code. Developers and system administrators need to work together to ensure that the entire stack is configured properly.

(A6) Sensitive Data Exposure

Developers have full control over which data is displayed in a zul page, and must avoid exposing sensitive data.

(A7) Missing Function Level Access Control

Since ZK is programmed in Java language, developers have full control over the availability of backend service functions.

(A8) Cross-Site Request Forgery (CSRF)

Please refer to our document on this topic.

(A9) Using Components with Known Vulnerabilities

ZK addresses known vulnerabilities at high priority. Once identified, we provide updates and patches as soon as possible. Hence, it is recommended to upgrade to the latest version when it becomes available.

(A10) Unvalidated Redirects and Forwards

Since ZK is a web application running in a servlet container, the developer has control over forwards/redirects to external URLs.

References

  1. ↑ The Open Web Application Security Project official website
  2. ↑ The OSWAP Top 10 document
Retrieved from "https://www.zkoss.org/_w/index.php?title=ZK_Developer%27s_Reference/Security_Tips/OWASP_Top_10_Security_Concerns_In_2013&oldid=47177"