Domain

11. OWASP Top 10

Every vibrant technology marketplace needs an unbiased source of information on best practices, as well as an active body advocating open standards in the application security space. One of those groups is the Open WebApplication Security Project, or OWASP for short. It operates as a nonprofit and is not affiliated with any technology company, which means it is in a unique position to provide impartial practical information about abstract individuals, corporations, universities, governments, agencies, and other organisations worldwide. Operating as a community of like-minded professionals, OWASP issues software tools and knowledge-based documentation on application security. All of its articles, methodologies, and technologies are made available free of charge to the public. OWASP makes available a list of the top ten most critical web application security risks. Let's take a look at the OAS top ten for 2017. If you navigate to Oas.org, you'll see this web page here. I'm going to go ahead and click on OS Top 10: 20: 17. Now, when we come to this page,this is initially what you'll see. It's a PDF document. I'd like to draw your attention to page six. This page has something that I personally find very interesting. It actually shows you what the application security risks are and the threat agents, the vectors, the actualweakness, what kind of security controls there would be,the technical impacts and the business impacts, and it actually shows you the route that it would take. This is actually very helpful to know. The whole document here actually has quite a bit of useful information. But let's go ahead and jump over to page seven here, which actually has the list of top ten security risks for 2017. The top ten security risks areinjection, broken authentication, sensitive data exposure,XML, external entities, broken access control,security misconfigurations, cross-site scripting, insecure deserialization components with known vulnerabilities, and insufficient logging and monitoring. Now, we're not going to go through each one of these individually. It would simply be too redundant. Everything is listed here. I would highly encourage you to take a look at this information and if you feel that you need more information on each one of these, a simple Google search will provide you with plenty of information on that. The details of this go well beyond the scope of this course in terms of going into detail, but we will look at a few of these in more detail. For example, we will look at SQL injections and will also look at cross-site scripting in further detail. If you actually scroll down this document, you'll see that each one of them is actually explained. For example, one of the top ten vulnerabilities is injection. It tells you what the threat agent is, the attack vectors are, and it goes into quite a bit of detail to provide you with real world examples. So here's one example here of an attack scenario, and it does the same thing for the other nine vulnerabilities. So here we have broken authentication. It gives you all the details you need. There. same thing with sensitive data exposure. This document is well worth the read. It provides quite a bit of information and is time well spent.

12. SQL Injection Prevention

The danger of SQL injections has been known for 15 years, and yet such attacks are still one of the greatest dangers to dynamic websites, which can cause serious damage, including the destruction of the data in your database. But what exactly are they and how can you prevent them from understanding a SQL injection? Let's start with an explanation of what a SQL is. SQL, otherwise known as structured Query language, is a domain-specific language used in programming and designed for managing data held in a relational database management system or for stream processing in a relational data stream management system. Okay, great, so we know what a sequel is. But what is a sequel injection? On the modern web, you can find lots of dynamic sites which are generated on the fly. A scripting language such as PHP retrievescontent from a database and puts it together based on instructions or statements. Such instructions contain the code written by the developer as well as the data the visitorenters via the web form, for example, when he or she enters his login and password. If a developer is not careful enough when writing his or her statements, ill-intentioned people will have the opportunity to slip malicious code into the data at the end, allowing them to execute other instructions. So in short, hackers use certain characters or formulas in the input field of the form, as a result of which their input is no longer seen as a simple string, but rather as a function. So let's look at some of these most common signs. An asterisk is an instruction for the SQL database to show all columns for the selected row in the database. Equals is an instruction for the SQL database to show only the values that match the search string. A simple quote is used to tell the SQL database where the search string begins or ends. A semicolon is used to tell the sequelparser that the current statement is terminated. A double dash is used to tell the sequel parser that the rest of the row is a comment. It should not be executed. What are the dangers of a sequel injection? As previously stated, SQL injection is an attack in which extra code is added to the input. If no precautions are taken in the script to anticipate such situations, the code will be executed, leading to dangerous situations. The attacker can add, edit, or read the database content; read the source code of files on the database server; write files to the database server; and these are just a few simple examples. Here is an example that should clearly illustrate this. This code is used as a SQL statement whose purpose is to select a user with a specific ID. But what if the user enters the code below as his user ID in the form? The statement then becomes select stars from users where user ID equals 105 or one equals one. The consequence of this is that although the initial purpose was to show a single row that the user ID entered into the input. All the rows are now shown. Because the or condition is always true, one equals one,and when the users table does not only contain usernames but also passwords, you are in big trouble. If I was trying to defend against SQL injection attacks, I could use two techniques: input validation and parameterised queries. Input validation occurs when the Web application inspects the input provided by a user to make sure that it's in an appropriate format. For example, the input should never contain a single quotation mark. This check should always be performed by the Web application on the server, where an attacker can't modify the code. If the developer tries to use a technique known as client-side validation, where the user's browser validates input, an attacker can easily remove those checks and bypass the input validation security. The second SQL injection prevention technique is the use of parameterised SQL commands. Using this technique, SQL statements are stored on a server, sometimes in a precompiled format, where the input provided by applications is plugged in after the sequel is already processed. This type of query also protects against a sequel injection attack.

13. Cross-Site Scripting (XSS) Prevention

In this lesson, we will be discussing cross-site scripting and its prevention. Cross-site scripting refers to client-side code injection attacks in which an attacker can inject malicious script, also known as a malicious payload, into a legitimate website or web application. Cross-site scripting is one of the most common web application vulnerabilities, and it occurs when a web application uses unvalidated or unencoded user input in the output it produces. By leveraging cross-site scripting, an attacker does not target a victim directly. Instead, an attacker would exploit a vulnerability within a website or web application that the victim would visit, essentially using the vulnerable website as a vehicle to deliver malicious script to the victim's browser. A cross-site script vulnerability arises when web applications take data from users and include it dynamically in webpages without first properly validating the data. Crosssite script vulnerabilities allow an attacker to execute arbitrary commands and display arbitrary content in a victim user's browser. A successful XSS attack leads to the attacker controlling the victim's browser or account on the vulnerable web application. Although excess is enabled by vulnerable pages in an application, the victims of an XSS attack are the application's users, not the application itself. The potency of an XSS vulnerability lies in the fact that the malicious code is executed in the context of the victim's session, allowing the attacker to bypass normal security restrictions. Reflected cross-site scripting occurs when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is nonprofit and only impacts the users who open a maliciously crafted link or thirdparty web page. There are many ways in which an attacker can entice the victim into initiating a reflective excess request. For example, the attacker could send the victim a misleading email with a link containing malicious JavaScript. If the victim clicks on the link, the http request is initiated from the victim's browser and sent to the vulnerable web application. The malicious JavaScript is then reflected back to the victim's browser, where it is executed in the context of the victim's session. Persistent Crosssite Scripting The persistent crosssitescripting vulnerability is a more devastating variant of the crossside scripting flaw. It occurs when the data provided by the attacker is saved by the server and then permanently displayed on normal pages, returning to other users in the course of regular browsing without proper HTML escaping. Consider a web application that allows users to enter a username that is displayed on each user's profile page. The application stores each username in a local database. A malicious user notices that the web application fails to sanitise the username field and inputs malicious JavaScript code as part of their username. When other users view the attacker's profile page, the malicious code automatically executes in the context of their sessions. When attackers succeed in exploiting excess vulnerabilities,they can gain access to account credentials. They can also spread web worms or access the user's computer and view the user's browser history or control the browser remotely. After gaining control of the victim system, attackers can also analyse and use other intranet applications. By exploiting access vulnerabilities, an attacker can perform malicious actions such as hijacking an account, spreading web worms, accessing browser history and clipboard contents, controlling the browser remotely, and scanning and exploiting internet appliances and applications. So how do we prevent cross-site scripting? Well, the best way to do it is to use inbound validation. In other words, do not allow scripttags and user-supplied input.

14. Cross-Site Request Forgery (XSRF)

Let's turn our attention to cross-site requestforgery and how to defend against it. Cross-site request forgery, also known as a one-click attack or session writing and abbreviated as Caesaror XSRF, is a type of malicious exploit of a website where unauthorised commands are transmitted from a user that the web application trusts. Cross-site request forgery has several key concepts. First, malicious requests are sent from a site that a user visits to another site that the attacker believes the victim is validated against. Next, the malicious requests are routed to the target site via the victim's browser,which is authenticated against the target site. Third, the vulnerability lies in the affected web application, not the victims' browser or the site hosting the CSIR and a cross-site requestforgery attack. The attacker is exploiting how the target web application manages the authentication. For Cserf to be exploited, the victim must be authenticated against the target site. For instance, let's say Mybank.com has online banking that is vulnerable to Caesar. If I visit a page containing a Cserf attack on Mybank.com but I'm not currently logged in, nothing happens. If I am logged in, however, the requests will be executed as if they wereactions that I had intended to take. Let's take a closer look at this type of attack. First, let's assume that I'm logged into Myaccount@mybank.com, which allows for standard online banking features,including transferring funds to another account. Let's say I happened to visit attacker.com. It just so happens that this site is trying to attack people who bank with Mybank.com and has set a C-Serv attack on this site. The attack will transfer $1,000 to an account somewhere on attacker.com. Attackers have added this line of code upon loading that iframe My browser will send that request to Mybank.com, where my browser has already logged in as me. The request will be processed and sent to the account for $1,000. The most common method to prevent cross-site request forgery attacks is to append Cserf tokens to each request and associate them with the user session. Such tokens should, at a minimum, be unique per user session but can also be unique per request. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from a source other than the user. Other options for defending against crosssite request forgeryattacks include re-architecting web applications, preventing the use of Http Get requests, advising users to logout of sites, and automatically logging out users after a natal period.

15. Understanding Encryption

We've all heard the term "encryption." But what is encryption? Encryption is the process of encoding a message or information in such a way that only authorised parties can access it and those who are not authorised cannot. It converts information from plaintext into encrypted ciphertext. But how does it do this? Encryption uses algorithms. An algorithm is the procedure that the encryption process follows. The specific algorithm is called a decipher, or code. There are many types of encryption algorithms. The encryption's goal and level of security determine the most effective solution. Tripled as RSA and Blowfish are some examples of encryption algorithms or ciphers. If that's encryption, then what's decryption? Decryption is the process of taking encoded or encrypted text or other data and converting it back into text that you or the computer can read and understand. Decryption converts information from encrypted text into plain text. So here's a very basic example of how this works. Let's say you send a message. Your phone gets the key from the app server and encrypts the message so only your friend can open it. Then your friend's phone receives a message and decrypts it using their personal key. Finally, your friend reads the message. That is a basic example of encryption decryption. Another thing you should be familiar with is private and public keys. And this is central to the concept of encryption. A private key or symmetric key means that the encryption and decryption keys are the same. The two parties must have the same key before they can achieve secure communication. So what's a public key? A public key means that the encryption key is published and available for anyone to use. Only the receiving party has access to the decryption key that enables them to read that message. Here is an example: Let's assume you are the sender of a plain text message. That plain text message is encrypted using the recipient's public key. Once that's been done, it's converted into ciphertext. That ciphertext is then decrypted. It's decrypted using the recipient's private key. Upon completion, the decrypted message becomes plain text once again and is sent to the recipient. As you can see, there's a public key and a private key involved in this process.

ExamSnap's ISC CISSP Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, ISC CISSP Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.