OWASPTop10_and_more

A+T+V = R
Asset + Threat + Vulnerability = Risk

Assets are people, property and information. AN ASSET IS SOMETHING WE WANT TO KEEP SAFE.

Threats exploit vulnerabilities, by accident or on purpose, and obtain, alter or destroy an asset. A THREAT IS SOMETHING YOU PROTECT AGAINST.

Vulnerabilities are weaknesses or gaps in security programs that can be exploited to gain unauthorized access to an asset. A VULNERABILITY IS A WEAKNESS THAT MAKES A THREAT FORMIDABLE.

Risk is the potential for loss, damage or destruction due to a threat. RISK IS THE RESULT OF OUR ASSETS, THREATS THAT FACE THEM AND VULNERABILITIES IN OUR EFFORTS TO KEEP THEM SAFE.



Hashing: One way. For integrity.
	Hashes are created from data using a one-way, well known and repeated method. No matter the size of the input, the output is always the same. Two files will have the same hash if they are identical, but a small change in either one will produce a significantly different hash.

Encryption: Two Way, key required. For confidentiality
	Plaintext: 	 h e l l o
	Key:	1 2 3 4 5
	Ciphertext: I G O P T 		This process is reversible

Encoding: Transforming data from one representation to another. For usability.
	2 -> encoded in decimal for humans.    0010 -> encoded in binary for computers

Obfuscation: An attempt to mask content to make it harder for an entity to recognize. For stealth.
	Yuo may siltl be albe to raed tihs, eevn toghuh the wrdos are msilplesd.




CROSS SITE REQUEST FORGERY (CSRF)
	A request triggered to the server-side of an application, not just from the application frontend. A CSRF attack is when an authenticated user is tricked into interacting with a 3rd-party application that ends up sending a malicious request to the real application. All the real server sees is an HTTP request from an authenticated user.

	This can cause actions to be executed as that user. An attacker can cause a password change, make comments, etc. Any action a regular user can take is potentially a risk. The attack can attempt to snare other users into the same trap.

	An application is vulnerable to CSRF if it does not use anti-forgery tokens cookies or require additional authentication for sensitive actions. If an application uses GET requests to send information, it may be vulnerable to CSRF. REST API's are designed ensure GET requests are only used to view information.


CROSS SITE SCRIPTING (XSS)

	Stored (or Persistent) XSS: Malicious script injected on a page remains and is run whenever the page is loaded.  This can be used to steal other user's cookies and sessions, redirect pages to malicious clones, and run any other action the attacker creates.
	Reflected XSS requires a malicious link be crafted in such a way that the script is run when the link is visited. If user inputted terms are included in the URL directly, the potential for reflected XSS increases. The script is not stored on the page.
	DOM-Based XSS is similar to Reflected XSS, but occurs entirely within a victim’s browser, and does not require the attacker’s script to be processed by the application’s server. URI fragments are handled by client-side Javascript, which can be vulnerable to XSS.
	An application is vulnerable to XSS if it does not properly sanitize, escape or validate user input. The risk is increased if that user input is logged and displayed to other users. An acceptable character whitelist is preferable to a blacklist, which has more room for error. A content security policy can be put in place that prevents inline Javascript from running at all. URI fragments that are not handled safely are vulnerable to DOM-Based XSS.



INJECTION
	Injection occurs when an attacker sends maliciously crafted command or query that is directly handled by a server or database. In a database, an attacker can inject queries that deliver more information than expected or affect an application's logic to allow access to restricted areas. Commands successfully injected through the application may be run directly on the server, giving the attack the ability control the system.

	An application is vulnerable to injection if input is not properly sanitized and/or parameterized. Symbols included as part of a language's syntax must be escaped, or they will be interpreted as a command, not a string. Character whitelisting will assist in sanitization. Object-relation mapping included in design frameworks can minimize the potential for developers to write vulnerable applications.


BROKEN ACCESS CONTROL
	 Simply hiding information is not sufficient to keeping it secure. It may eventually be found. Use of common terms or a predictable naming scheme for resources will increase the likelihood of these resources being found. Sensitive resources must only be accessible by administrators, and a least-privilege access model is best practice.

	Access control relies on three parts. Authentication, Authorization and permissions checking. A leak in any of these three can result in compromise of the other two.
	 Authentication procedures must reliably verify that a user is who they say they are. If a user can be impersonated, a malicious actor gains access to all resources and actions at that user's disposal. MFA and good password hygiene is essential. A user can only perform authorized actions. Ideally, this follows the least-privilege model.
	Authorization must be re-verified. In the event that an administrator's session is hijacked, an additional password check on sensitive actions may prevent an attack from performing malicious actions.


XML EXTERNAL ENTITIES (XXE)
	XML document structure can be validated against a Document Type Definition for correctness. These can be in-lined and may refer to external entities. XML packets can be constructed to refer to malicious entities that cause sensitive information to be revealed.
	An application can be made more secure by disabling inline XML DTD parsing. Web application processes should follow the privilege of least privilege. Simpler data formats, such as JSON, may be less likely to reveal sensitive information.



SECURITY MISCONFIGURATION
	Applications are only as secure as people set them up to be. Default configurations may implement poor or absent access controls, use widely known default credentials and require manual updates. These configurations may also include unnecessary features, such as debuggers, which increase attack surface.
	Proper configuration requires attention and effort. Operational security is a marathon, not a sprint. Employ the principles of least privilege and compartmentalization. Never use hard-coded credentials. Once secure deployment, maintenance and build processes have been established, they should be automated for ease of implementation and reduction of human error. Configuration and code should be separate, so the same functionality can be implemented across multiple locations without credential sharing.


INSECURE DESERIALIZATION
	To facilitate data transmission, information is often sent in "bundle" formats that are easier to handle and can be "unraveled" later. These serialized bundles may not be adequately secured and may contain sensitive information. If an attacker is able to figure out how to deserialize and reproduce serializations, they may be able to create another avenue of attack against an application or server. These serializations may contain sensitive cookies, user IDs, password hashes, or tokens.

	An application can be made more secure by refusing to accept serialized objects from untrusted sources, or to use serialization schemes that only permit primitive data types. Serialized objects can be secured with digital signatures, and deserialization processes should run with as few privileges as possible. Deserialization exceptions and failures should be logged and monitored.


USING COMPONENTS WITH KNOWN VULNERABILITIES
	Modular applications are built from multiple components, some of which may be independently developed and maintained. Exploitation of a vulnerable component may lead to further exploitation of an application. These components can exist in any part of the application's structure.
	Ensuring all components of an application are without vulnerabilities is a highly customized process. Administrators must continuously inventory all components used, know their versions, and check them for vulnerabilities, and update as necessary. A vulnerable component without a patch may need to be removed. All components should come from official sources and must be verified before installation. It is the application administrator's responsibility to update third-party applications. In order to keep this maintenance process manageable, unused components, features, files, dependencies and documentation should be removed.



INSUFFICIENT LOGGING AND MONITORING
	Without monitoring, exploitation may never be detected, let alone mitigated. Logging and monitoring are essential to responding to attacks, as they may provide the only evidence of what an attacker was able to accomplish. Logs act as a record of how an attack unfolded, indicate which processes require improvement, and may even serve as evidence a crime was committed. Without effective monitoring, an incident may go unnoticed until long after damage has been done. Logs and monitoring efforts are the cornerstone of any incident response plan.

•	Logs must have strict access control and redundant, encrypted backups in multiple locations.
•	Login attempts and “high impact” transactions should be logged
•	Log content must be informative and provide enough context to identify suspicious activity.
•	Log management software exists, and logs must be formatted to be handled by them
•	Behavior associated with automated penetration testing software must be recognized and logged.
•	Monitoring and alert processes must have appropriate speed, security and sensitivity. If too many alerts are generated, they will eventually be ignored. If too few alerts are generated, personnel may miss suspicious behavior.
•	An Incident Response plan that follows official guidelines must be created, frequently revisited, and improved.