Thinking about a new web application that could be the following enormous thing that clients run to? You're probably giving more consideration to the features of this new application as opposed to a standout amongst the most significant parts of it that could send individuals running for the hills: security, or the lack thereof.
The OWASP Top 10 is a consistently updated report sketching out security concerns for web application security, concentrating on the 10 most critical risks. The report is put together by a group of security specialists from everywhere throughout the world. OWASP alludes to the Top 10 as an 'awareness document' and they suggest that all organizations join the report into their processes so as to limit and/or reduce security risks.
Below are the security risks reported in the OWASP Top 10 report:
1. Injection – One of the easiest exploits of any website which has become even easier as more automated tools are developed to make the process faster. It occurs when untrusted data is sent to an interpreter. Prevention of such an attack can be made by setting boundaries on the input data to only accept data within those boundaries, a so-called “whitelist” of data. In addition to the whitelist, try to use a parameterized interface and also escape the input data.
2. Cross-Site Scripting (XSS) – The most prevalent web application security flaw, according to OWASP. It occurs when user-supplied data is not escaped and/or validated. While most prevalent, it is also one of the easiest to prevent. Simply escape data and only accept data that is of the correct type, length, name and/or value, a so-called whitelist.
3. Broken Authentication and Session Management – Custom authentication schemes commonly suffer from such vulnerabilities as these because the development of custom authentication schemes is hard and the developer inadvertently doesn’t account for one or more of the common flaws. The prevention of such flaws can be by forcing developers to use a single set of authentication and session management controls.
4. Insecure Direct Object References – A developer might use the key names of database fields in forms on their web application. The attacker changes the name of the form field with a different value that they may not be authenticated for and submits the data. The prevention of such an attack can be made by simply adding abstraction to the fields of the database so that the field names are not known to the attacker.
5. Security Misconfiguration – The entire “stack”—the technologies that, when stacked up, facilitate an application to function—needs to be secure or else other attack vectors can be exploited. For example, a couple of years ago it was found that MySQL databases would allow an attacker to log in to a database after 255 tries of the password. Any affected database that was exposed to the internet i.e. not filtered with a firewall, could be directly accessed without the need to go through the web application in order to be exploited. Prevention of such attacks can be made by ensuring that both developers and IT staff collaborate and continuously audit their systems for such flaws.
6. Missing Function Level Access Control – A malicious and authenticated user changes a parameter of the URL and is able to gain access to a function of the website because the developer didn’t check to make sure the user should have access to that function. The prevention of such an attack is as simple as making sure that if a function is accessed, the user has the right to access it.
7. Cross-Site Request Forgery (CSRF) – Allowing data to be sent to a server without also including an unpredictable token value that the server already knows would allow such an attack. A user could go from one website to another, malicious, one where the malicious one would send seemingly authenticated data without the knowledge of the user. Prevention of such an attack is easy. Just set an unpredictable token in the session and have the form submit it as another field. Clear the token on form submission so each new submission has a unique value.
8. Sensitive Data Exposure – One of the more difficult exploits, it typically occurs when the developer uses no data encryption, or weak data encryption, or weak keys and/or weak encryption and hashing algorithms. As technology advances, hashing and encryption algorithms should be used and kept updated to the latest versions.
9. Unvalidated Redirects and Forwards – An attacker can trick a user into clicking on a link that contains an unvalidated parameter, which allows a redirect to a page with higher administrative privileges. Prevention can be not using redirects/forwards; if redirects/forwards are used, then validate the redirect parameters and ensure the user has the appropriate privileges to access the redirected/forwarded page.
10. Using Components with Known Vulnerabilities – Developers may not check to see if components, such as plugins, have known vulnerabilities before using them in a web application. As vulnerabilities are commonly widely published as a means to inform developers, attackers can use the same published data to create attack vectors for web applications. Prevention includes checking public information to see if any components of the web application are vulnerable; create security tests for the components that scan for common vulnerabilities; add an abstraction layer to the component to restrict what data can be input and output by it.
What’s next for Developers?
Regardless of whether you're new to web application security or already acquainted with these risks, the task of delivering a safe web application or fixing an existing one can be troublesome. If you need to manage with a large application portfolio, this task can be overwhelming. To support organizations and developers diminish their application security hazards in a cost-effective manner, OWASP has created various free and open resources that you can use to address application security in your organization.
OWASP recommends organizations set up an application security program to pick up knowledge and improve security over their applications and APIs. Accomplishing application security requires a wide range of parts of an organization to cooperate efficiently, including security and review, software development, business, and official administration. Security ought to be visible and quantifiable, so all the various players can see and comprehend the organization’s application security act.
No comments:
Post a Comment