Website Vulnerabilities Flashcards
Clickjacking
Clickjacking attacks trick web users into performing an action they did not intend, typically by rendering an invisible page element on top of the action the user thinks they are performing. Clickjacking attacks wrap a page the user trusts in an iframe, then renders invisible elements on top of the frame.
What could a determined hacker do with a clickjacking attack?
• Harvest login credentials, by rendering a fake login box on top of the real one. • Trick users into turning on their web-cam or microphone, by rendering invisible elements over the Adobe Flash settings page. • Spread worms on social media sites like Twitter and MySpace. • Promote online scams by tricking people into clicking on things they otherwise would not. • Spread malware by diverting users to malicious download links.
Clickjacking protection
To ensure that your site doesn’t get used in a clickjacking attack, you need to make sure it cannot be wrapped in an iframe by a malicious site. This can be done by giving the browser instructions directly via HTTP headers, or in older browser by using client-side JavaScript (frame-killing).
Cross-site scripting (XSS)
XSS vulnerabilities permit a malicious user to execute arbitrary chunks of JavaScript when other users visit your site.
What could a determined hacker do when exploiting a XSS vulnerability?
XSS allows arbitrary execution of JavaScript code, so the damage that can be done by an attacker depends on the sensitivity of the data being handled by your site. Some of the things hackers have done by exploiting XSS: Spreading worms on social media sites. Facebook, Twitter and YouTube have all been successfully attacked in this way. Session hijacking. Malicious JavaScript may be able to send the session ID to a remote site under the hacker’s control, allowing the hacker to impersonate that user by hijacking a session in progress. Identity theft. If the user enters confidential information such as credit card numbers into a compromised website, these details can be stolen using malicious JavaScript. Denial of service attacks and website vandalism. Theft of sensitive data, like passwords. Financial fraud on banking sites.
To protect against stored XSS attacks
make sure any dynamic content coming from the data store cannot be used to inject JavaScript on a page. Whitelist Values If a particular dynamic data item can only take a handful of valid values, the best practice is to restrict the values in the data store, and have your rendering logic only permit known good values. For instance, instead of asking a user to type in their country of residence, have them select from a drop-down list. Implement a Content-Security Policy Modern browsers support Content-Security Policies that allow the author of a web-page to control where JavaScript (and other resources) can be loaded and executed from. XSS attacks rely on the attacker being able to run malicious scripts on a user’s web page
Reflected XSS attacks
Any page that takes a parameter from a GET or POST request and displays that parameter back to the user in some fashion is potentially at risk. A page that fails to treat query string parameters as untrusted content can allow the construction of malicious URLs.
Reflected XSS vulnerabilities
Search results - does the search criteria get displayed back to the user? Is it written out in the page title? Are you sure it is being escaped properly? Error pages - if you have error messages that complain about invalid inputs, does the input get escaped properly when it is displayed back to the user? Does your 404 page mention the path being searched for? Form submissions - if a page POSdataTs , does any part of the data being submitted by the form get displayed back to the user? What if the form submission is rejected – does the error page allow injection of malicious code? Does an erroneously submitted form get pre-populated with the values previously submitted?
To protect against reflected XSS attacks
make sure that any dynamic content coming from the HTTP request cannot be used to inject JavaScript on a page. Also see XSS protection techniques
Command Execution
Remote code execution is a major security lapse, and the last step along the road to complete system takeover. After gaining access, an attacker will attempt to escalate their privileges on the server, install malicious scripts, or make your server part of a botnet to be used at a later date. Command injection vulnerabilities often occur in older, legacy code, such as CGI scripts.
Command Execution protection
Try to Avoid Command Line Calls Altogether Modern programming languages have interfaces that permit you to read files, send emails, and perform other operation system functions. Use APIs wherever possible – only use shell commands where absolutely necessary. This will reduce the number of attack vectors in your application, and will also simplify your codebase. Escape Inputs Correctly Injection vulnerabilities occur when untrusted input is not sanitized correctly. If you use shell commands, be sure to scrub input values for potentially malicious characters: ; & | ` Even better, restrict input by testing it against a regular expression of known safe characters. (For example, alphanumeric characters.) Restrict the Permitted Commands Try to construct all or most of your shell commands using string literals, rather than user input. Where user input is required, try to whitelist permitted values, or enumerate them in a conditional statement. Perform Thorough Code Reviews Check system calls for vulnerabilities as a part of your code review process. Vulnerabilities often creep in over time – make sure your team knows what to look for. Run with Restricted Permissions It is a good practice to run your server processes with only the permissions that they require to function – the principle of least privilege. This can help limit the impact of command injection vulnerabilities as a second line of defense. Make sure each web server process can only access the directories that it needs, and narrow down the directories in which they write or execute files. Consider running the process in a chroot jail if you are running on Unix. This will limit the ability of maliciously injected code to “climb out” of a directory.
API
Application Programming Interface In computer programming, an application programming interface (API) is a set of subroutine definitions, protocols, and tools for building application software. In general terms, it is a set of clearly defined methods of communication between various software components.
SQL injection
SQL injection is a type of injection attack. Injection attacks occur when maliciously crafted inputs are submitted by an attacker, causing an application to perform an unintended action. Because of the ubiquity of SQL databases, SQL injection is one of the most common types of attack on the internet.
SQL injection risks
Extract sensitive information, like Social Security numbers, or credit card details. Enumerate the authentication details of users registered on a website, so these logins can be used in attacks on other sites. Delete data or drop tables, corrupting the database, and making the website unusable. Inject further malicious code to be executed when users visit the site.
SQL protection
Parameterized Statements Programming languages talk to SQL databases using database drivers. A driver allows an application to construct and run SQL statements against a database, extracting and manipulating data as needed. Parameterized statements make sure that the parameters (i.e. inputs) passed into SQL statements are treated in a safe manner. Object Relational Mapping Many development teams prefer to use Object Relational Mapping (ORM) frameworks to make the translation of SQL result sets into code objects more seamless. ORM tools often mean developers will rarely have to write SQL statements in their code – and these tools thankfully use parameterized statements under the hood. The most well-known ORM is probably Ruby on Rails’ Active Record framework. Escaping Inputs Sanitizing Inputs Check that supplied fields like email addresses match a regular expression. Ensure that numeric or alphanumeric fields do not contain symbol characters. Reject (or strip) out whitespace and new line characters where they are not appropriate.
XSS attack diagram
