What type of application attack involves the hacker inputting into a web site data that contains script code that will execute when the page is viewed by another visitor?
|
Editor’s note: This article was updated on 08/12/2022 by our editorial team. It has been modified to include recent sources and to align with our current editorial standards. Show
For all too many companies, it’s not until after a security breach has occurred that web security best practices become a priority. During my years working as an IT security professional, I saw—time and time again—how obscure the world of web development security issues can be to so many of my fellow programmers. An effective approach to web security threats must, by definition, be proactive and defensive. Toward that end, we aim to spark a security mindset and to inject the reader with a healthy dose of paranoia. In particular, this guide focuses on developing an awareness of and mitigating 10 common and significant web security pitfalls.  Authentication and Authorization: A Cyber Security PrimerProgrammers and IT professionals often express confusion regarding the distinction between authorization and authentication. The use of the abbreviation auth for both terms increases the haziness that surrounds them. Let’s define and clarify the distinction:
Stated another way, authentication is knowing who an entity is, while authorization is what a given entity can do. With this in mind, let’s explore 10 common internet vulnerability issues. Injection FlawsInjection flaws result from a classic failure to filter untrusted input. Injection flaws can happen when we pass unfiltered data to the SQL server (SQL injection), to the browser (via Cross Site Scripting), to the LDAP server (LDAP injection), or anywhere else. The problem here is that the attacker can inject commands to hijack clients’ browsers, resulting in loss of data. Anything that your application receives from an untrusted source must be filtered, preferably according to a whitelist. Using a blacklist to this end is not recommended, as it is difficult to configure properly. A blacklist is also considered easy for a hacker to bypass. Antivirus software products typically provide stellar examples of failing blacklists. Pattern matching does not work. Prevention: Protecting against injection is “simply” a matter of filtering our input and considering which senders can be trusted. Filtering is quite an undertaking because we need to process all input unless it can unquestionably be trusted. If we filter 999 inputs in a system with 1,000 inputs, we still have one field that can be the Achilles’ heel that brings down our system. Using Second Order SQL Injection to inject one SQL query result into another is also considered dangerous. It could seem like a good idea because the database is trusted. But if the perimeter is not, our input could originate indirectly from a malicious source. Since filtering is pretty hard to get right, it is advisable to rely on our framework’s filtering functions. They are proven to work and thoroughly scrutinized. If you do not already use a framework, consider the server security benefits of moving to one. . Broken AuthenticationProblems that might occur during broken authentication don’t necessarily stem from the same root cause. Rolling your own authentication code is not recommended, as it is hard to get right. There are myriad possible pitfalls, and here are a few:
Prevention: The most straightforward way to avoid the web security vulnerabilities related to broken authentication is to implement a framework. If you roll your own code, be extremely paranoid and educate yourself on the potential issues that could arise. Cross-Site Scripting (XSS)An attacker sends on input JavaScript tags to your web application. When this input is returned to the user unsanitized, the user’s browser would execute it. This is a fairly widespread input sanitization failure, essentially a subcategory of injection flaws). CSS can be as simple as crafting a link and persuading a user to click it, or it can be something much more sinister. For example, on page load, the script would run and be used to post your cookies to the attacker. Prevention: Simply put, don’t return HTML tags to the client. This would also protect you from HTML injection, which is when an attacker injects plain HTML content (such as images or loud but invisible flash players). To implement this solution, convert all HTML entities to return something else. For example, convert Insecure Direct Object ReferencesThis is a classic case of trusting user input and paying the price by inheriting a resultant security vulnerability. A direct object reference means that an internal object (e.g., a file or a database key) is exposed to the user, leaving us vulnerable to attack. The attacker can provide this reference, and if authorization is either not enforced or broken, the attacker gets in. For example, the code has a download.php module that reads and lets the user download files, using a CGI parameter to specify the file name (e.g., download.php?file=something.txt). If the developer omitted authorization from the code, the attacker can now use it to download system files accessible to the user running PHP (e.g., the application code or random server data like backups). Another example of insecure direct object reference vulnerability is a password reset function that relies on user input to determine their identity. After clicking the valid URL, an attacker could modify the username field in the URL to say something like “admin.” Incidentally, I have seen both of these examples often “in the wild.” Prevention: Perform user authorization properly and consistently, and whitelist the choices. More often than not, the vulnerability can be avoided altogether by storing data internally and not relying on data being passed from the client via CGI parameters. Session variables in most frameworks are well suited to this purpose. Security MisconfigurationIn my experience, it is common to encounter misconfigured web servers and applications. Some examples:
Prevention: Have a good (preferably automated) “build and deploy” process, which can run tests on deploy. The poor man’s security misconfiguration solution is post-commit hooks, to prevent code from going out with default passwords and/or development stuff built in. Sensitive data exposureThis web security vulnerability is about crypto and resource protection. Sensitive data should be encrypted at all times, including in transit and at rest. No exceptions. Credit card information and user passwords should never travel or be stored unencrypted, and passwords should always be hashed. Obviously, the crypto/hashing algorithm must not be a weak one. When in doubt, web security standards recommend AES (256 bits and up) and RSA (2048 bits and up). It cannot be overemphasized that session IDs and sensitive data should not travel in URLs. Cookies with sensitive data should have the “secure” flag on. Prevention:
And at the risk of stating the obvious, do not store the encryption keys near their protected data. That’s like storing your bike with a lock that has the key in it. Protect your backups with encryption and keep your keys private. And of course, don’t lose the keys! Missing Function Level Access ControlThis is a failure that happens if proper authorization is not performed when a function is called on the server. Developers tend to assume that since the server side generates the UI, the client would not be able to access functionality that is not supplied by the server. It is not as simple as that, as an attacker can always forge a request to the “hidden” functionality. An attacker will not be deterred by the fact that the desired functionality is not easily accessible. Imagine there’s an /admin panel, and the button is only present in the UI if the user is actually an admin. Nothing keeps an attacker from discovering and misusing this functionality if authorization is missing. Prevention: On the server side, authorization must always be performed. Cross-Site Request Forgery (CSRF)In a CSRF—also referred to as a confused deputy attack—a malicious third party fools the browser into misusing its authority to do something for the attacker. In the case of CSRF, a third-party site uses your browser, cookies, and session to issue a request to a target site (e.g., your bank). If on one browser tab you are logged in to your bank, and if your bank is vulnerable to this type of attack, then another tab can be controlled to make your browser misuse its credentials on the attacker’s behalf, which results in the confused deputy problem. The deputy is the browser that misuses its authority (session cookies) to perform the attacker’s instructions. Consider this example: Attacker Alice wants to lighten target Todd’s wallet by transferring some of his money into her account. To send money, Todd accesses the following URL: https://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243 at his bank which, incidentally, is vulnerable to CSRF attacks. After Todd performs his transaction, a success page displays and the transfer is complete. Alice is aware that Todd frequently visits a site she controls at https://blog.aliceisawesome.com, so Alice places the
following snippet on her site: When Todd next visits Alice’s website, his browser wrongly thinks the snippet links to an image. The browser automatically issues an HTTP GET request to fetch the picture. But instead of getting an image to display in the browser, the request instructs Todd’s bank to transfer $1,500 to Alice. Incidentally, in addition to demonstrating the CSRF vulnerability, this example also demonstrates altering the server state with an idempotent (safe)HTTP GET request. This in itself a serious vulnerability. HTTP GET requests must be idempotent, meaning that they cannot alter the resource that is accessed. Never use idempotent methods to change the server state. Fun fact: CSRF is also the method people used for cookie-stuffing in the past until affiliates got wiser. Prevention: Store a secret token in a hidden form field, inaccessible to a third-party site. This, of course, requires you to verify the hidden field. Some sites may ask for a password before allowing you to modify sensitive settings (like a password reminder email). I suspect this could be to prevent the misuse of your abandoned sessions on public computers. Using Components With Known VulnerabilitiesThe title says it all. I’d classify this one as more of a maintenance/deployment issue. Before incorporating new code, do some research, and possibly some auditing. Using code from a random person on GitHub, for example, may be convenient, but it is not without risk of serious web security vulnerability. I have seen many instances where sites got owned (i.e., where an outsider gains administrative access to a system), because third-party software (e.g., WordPress plugins) remained unpatched for years in production. If you think they will not find your hidden phpmyadmin installation, let me introduce you to DirBuster. The lesson here is that software development does not end when the application is deployed. There has to be documentation, tests, and plans on how to maintain and keep the application updated, especially if it contains third-party or open source components. Prevention:
Unvalidated Redirects and ForwardsThis is yet another input filtering issue. Suppose that the target site has a redirect.php module that takes a URL as a GET parameter. Manipulating the parameter can create a URL on targetsite.com that redirects the browser to malwareinstall.com. A user would see the link as targetsite.com/blahblahblah, which looks innocuous enough to trust and click. But clicking this link could transfer the user to a malware drop (or any other malicious) page. Alternatively, the attacker might redirect the browser to targetsite.com/deleteprofile?confirm=1. It is worth mentioning that stuffing unsanitized user-defined input into an HTTP header might lead to header injection, which is pretty bad. Prevention: Options include:
EpilogueI hope I managed to tickle your brain and to introduce a healthy dose of paranoia and website security vulnerability awareness. The core takeaway here is that age-old software practices exist for a reason. What applied back in the day for buffer overflows still applies for pickled strings in Python today. Security protocols help us write better and safer programs, which we should aspire to do. Please use this knowledge responsibly, and don’t test pages without permission! For more information, see specific server side attacks and OWASP’s Attacks page. Feedback on this post and its mitigation advice is welcome and appreciated. To request a future article from me on web protection, feel free to contact me directly at . Here’s to website security! Cheers. Further Reading on the Toptal Engineering Blog:
Understanding the basicsInternet security threats are methods of abusing web technology to the detriment of a website, its users, or even the internet at large. Threats arise from websites that are misconfigured, were inadvertently programmed with vulnerabilities, or rely on components that are themselves vulnerable. The top internet security threats are always evolving, with injection and authentication flaws often at the top of the list. Open Web Application Security Project (OWASP), an international nonprofit organization, compiles and publishes its OWASP Top 10 annually. Make sure that any redirects your site makes (e.g., via HTTP headers, meta tags, JavaScript) do not rely on user input, or that any user input is sanitized (e.g., via a whitelist). A cross-site request forgery (CSRF) token lets a server know that a request is coming from auser on that site and not from another website the user is visiting. This is because the token is passed with every request via a hidden form field, preventing malicious sites from acting on behalf of their viewers via CSRF attacks. Also known as "dirty" or "untrusted" input, unvalidated input may be any input that is sent to your server. Using such input without sanitizing it first is a security vulnerability that can be turned against you or your users. SQL injection is when your code adds unvalidated input directly into an SQL statement, instead of using a parameterized query. Fortunately, parameterized query support is built into every database library, so SQL injection attacks are some of the easiest to mitigate. XSS (cross-site scripting) exploits misguided implementations of a common web application feature: the ability to receive HTML from one user and present it to others. Because unfiltered HTML can contain JavaScript, an attacker can receive it, then run code on behalf of another user (or users) when the other user returns to the web application. Security misconfiguration refers to undesired defaults in an application that's in production. Misconfiguration also refers to failing to install security updates in a timely manner. This is when the server is not programmed to verify authorization for a given function. Broken access control may result from a "security through obscurity" mindset: a false assumption that if a sensitive feature isn't prominently displayed, potential attackers will never find it. Sensitive data exposure is when an app (either by its own flaw or by an attacker's abuse of a vulnerability) reveals a user's private data (e.g., credit card numbers) to an unauthorized third party. Which of the following involves a hacker entering scripts into a web site that contains code that will execute when the page is viewed by another visitor?Cross-Site Scripting (XSS)
Instead, the malicious code the attacker has injected only runs in the user's browser when they visit the attacked website, and it goes after the visitor directly, not the website.
What type of attack involves the attacker inserting a client side script into the web page?Cross-site scripting (XSS) is an attack that involves the attacker inserting script code into a web page so that it is then processed and executed by a client system when a user browses that web page.
What type of attack can a hacker perform that involves injecting malicious code into a website to hijack a session cookie?A cross-site scripting (XSS) attack fools the user's machine into executing malicious code, although it thinks it secure because it seemingly comes from a trusted server. When the script runs, it lets the hacker steal the cookie.
What are the types of application attack?Below are some of the most common:. Cross-site scripting (XSS). ... . SQL Injection (SQLI). ... . Path traversal. ... . Local File Inclusion. ... . Distributed Denial of Service (DDoS) attacks.. |
