OWASP Top 10 Security Concerns In 2013"

From Documentation
 
(17 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? =
  
Line 5: Line 6:
 
= OWASP Top 10 in 2013 =
 
= OWASP Top 10 in 2013 =
  
−
In the subsections that follow, the top 10 security risks are compiled from OWASP site in a much condensed form. 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.
+
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)] ==
−
 
 
−
Since ZK does not provide any login mechanism, it is up to developers to choose and secure user authentication management mechanism on their own.
 
−
 
 
−
== Cross-Site Scripting (XSS) ==
 
−
 
 
−
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.
 
  
 
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.
 
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.
  
−
== Insecure Direct Object References ==
+
== [https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References (A4) Insecure Direct Object References] ==
  
−
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.
+
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.
  
−
Since ZK represents its internal components by string id's to the client-side, it cannot prevent improper disclosure of system resources. However, disabled/invisible components can be additionally secured by blocking their requests (see this [http://books.zkoss.org/wiki/ZK_Developer%27s_Reference/Security_Tips/Block_Request_for_Inaccessible_Widgets document]).
+
== [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.
 
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.
  
−
== Sensitive Data Exposure ==
+
== [https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure (A6) Sensitive Data Exposure] ==
−
 
 
−
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.
 
  
−
== Missing Function Level Access Control ==
+
Developers have full control over which data is displayed in a zul page, and must avoid exposing sensitive data.
  
−
Applications do not always protect application functions properly. Sometimes, function level protections is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget.
+
== [https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control (A7) Missing Function Level Access Control] ==
  
−
== Cross-Site Request Forgery (CSRF) ==
+
Since ZK is programmed in Java language, developers have full control over the availability of backend service functions.
  
−
CSRF takes advantage the fact that most web apps allow attackers to predict all the details of a particular action.
+
== [https://www.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF) (A8) Cross-Site Request Forgery (CSRF)] ==
  
−
Because browsers send credentials like session cookies automatically, attackers can create malicious web pages which generate forged requests that are indistinguishable from legitimate ones.
+
Please refer to our [http://books.zkoss.org/wiki/ZK_Developer%27s_Reference/Security_Tips/Cross-site_Request_Forgery document] on this topic.
  
−
== Using Components with Known Vulnerabilities ==
+
== [https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities (A9) Using Components with Known Vulnerabilities] ==
  
−
Virtually every application has these issues because most development teams don't focus on ensuring their components/libraries are up to date. In many cases, the developers don't even know all the components they are using, never mind their versions. Component dependencies make things even worse.
+
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.
  
−
== Unvalidated Redirects and Forwards ==
+
== [https://www.owasp.org/index.php/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards (A10) Unvalidated Redirects and Forwards] ==
  
−
Applications frequently redirect users to other pages, or use internal forwards in a similar manner. Sometimes the target page is specified in an unvalidated parameter, allowing attackers to choose the destination page.
+
Since ZK is a web application running in a servlet container, the developer has control over forwards/redirects to external URLs.
  
 
= References =
 
= References =
  
 
<references/>
 
<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"