Skip to main content

OWASP TOP 10 Application Security Risks - 2013


 The primary aim of the OWASP Top 10 is to educate developers, designers, architects, managers, and organizations about the consequences of the most important web application security weaknesses. The Top 10 provides basic techniques to protect against these high risk problem areas – and also provides guidance on where to go from here.

  • Injection
  • Cross Site Scripting (XSS)
  • Cross Site Request Forgery (CSRF)
  • Exposure of Sensitive Data
  • Security Misconfiguration
  • Using Components with Known Vulnerabilities
  • Unvalidated Redirects and Forwards
  • Broken Authentication and Session Management
  • Insecure Direct Object References
  • Missing Function Level Access Control

1) Injection

Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.


2) Cross Site Scripting (XSS)

 XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.


 3) Cross Site Request Forgery (CSRF)

A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests, so that the vulnerable application thinks that requests from the victim are legitimate.



4) Exposure of Sensitive Data

Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.


5) Security Misconfiguration

 Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.


6) Using Components with Know Vulnerabilities

 Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.


7) Unvalidated Redirects and Forwards

Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.


8) Broken Authentication and Session Management
9) Insecure Direct Object References.
10) Missing Function Level Access Control.

Comments

Popular posts from this blog

K8s External Secrets integration between AWS EKS and Secrets Manager(SM) using IAM Role.

What is K8s External Secrets and how it will make your life easier? Before saying about External Secrets we will say about k8s secrets and how it will work. In k8s secrets we will create key value pairs of the secrets and set this as either pod env variables or mount them as volumes to pods. For more details about k8s secrets you can check my blog http://jinojoseph.blogspot.com/2020/08/k8s-secrets-explained.html   So in this case if developers wants to change the ENV variables , then we have to edit the k8s manifest yaml file, then we have to apply the new files to the deployment. This is a tiresome process and also chances of applying to the wrong context is high if you have multiple k8s clusters for dev / stage and Prod deployments. So in-order to make this easy , we can add all the secrets that is needed in the deployment, in the AWS Secret Manager and with the help of External secrets we can fetch and create those secrets in the k8s cluster. So what is K8s external Secret? It i...

Setting /etc/hosts entries during the initial deployment of an Application using k8s yaml file

Some times we have to enter specific hosts file entries to the container running inside the POD of a kubernetes deployment during the initial deployment stage itself. If these entries are not in place, the application env variables mentioned in the yaml file , as hostnames , will not resolve to the IP address and the application will not start properly. So to make sure the /etc/hosts file entries are already there after the spin up of the POD you can add the below entries in your yaml file. cat > api-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: spec:   template:     metadata:     spec:       volumes:       containers:       - image: registryserver.jinojoseph.com:5000/jinojosephimage:v1.13         lifecycle:           postStart:             exec:               command:...

LXC Containers and How it differs from VMs and Docker Containers?

VM vs LXC ########## The main difference between the VMs and Containers is that virtual machines require their own kernel instance to run while  containers  share the same kernel. In other words,  containers  are virtualization at operating-system-level whereas  VMs  are virtualization at the hardware level. In virtual Machines each Guest OS will have its own Operating System and kernel. But in the case of LXC Containers the Guest OS will share the same OS of its Host machine. LXC vs Docker ############# LXC is a container technology that gives us the lightweight Linux containers and Docker is single application virtualisation which is based on top of the containerd Run time engine.. Thus even though based on container utilisation they may sound similar but they are completely different when it comes to usage. Unlike the lightweight LXC containers, docker does not tend to behave lightweight VM’s. Single application restriction of the docker is strictly by t...