START HACKING TODAY !

START BUG BOUNTY AND EARN MONEY

Search

Search

---

I AM NAWAB KHAN I START BUG BOUNTY IN YEAR 2020 AND I AM 17th YEAR OLD IN MY CHILDHOOD I AM A BIG FAN OF HACKER’S AND HACKING MOVIES SO I START MY CARRIER IN ETHICAL HACKING AND HACKING IS MY LIFE A DAY I AM TRYING TO HACK MY PHONE I WAS FAIL BUT I NEVER GIVE UP TO HACKING , HACKING ALSO SAY THAT FAILER IS NOT HAVE ANY OPTION FAILER SHOULD BE AN OPTION !

A bug bounty program is a deal offered by many websites, organizations and software developers by which individuals can receive recognition and compensation for reporting bugs, especially those pertaining to security exploits and vulnerabilities.

These programs allow the developers to discover and resolve bugs before the general public is aware of them, preventing incidents of widespread abuse. Bug bounty programs have been implemented by a large number of organizations, including Mozilla,^[3][4] Facebook,^[5] Yahoo!,^[6] Google,^[7] Reddit,^[8] Square,^[9] Microsoft,^[10][11] and the Internet bug bounty.^[12]

Companies outside the technology industry, including traditionally conservative organizations like the United States Department of Defense, have started using bug bounty programs.^[13] The Pentagon’s use of bug bounty programs is part of a posture shift that has seen several US Government Agencies reverse course from threatening white hat hackers with legal recourse to inviting them to participate as part of a comprehensive vulnerability disclosure framework or policy.

History

Hunter and Ready initiated the first known bug bounty program in 1983 for their Versatile Real-Time Executive operating system. Anyone who found and reported a bug would receive a Volkswagen Beetle (a.k.a. Bug) in return.^[15]

A little over a decade later in 1995, Jarrett Ridlinghafer, a technical support engineer at Netscape Communications Corporation coined the phrase ‘Bugs Bounty’.

Netscape encouraged its employees to push themselves and do whatever it takes to get the job done. Ridlinghafer recognized that Netscape had many product enthusiasts and evangelists, some of which could even be considered fanatical about Netscape’s browsers. He started to investigate the phenomenon in more detail and discovered that many of Netscape’s enthusiasts were actually software engineers who were fixing the product’s bugs on their own and publishing the fixes or workarounds, either in online news forums that had been set up by Netscape’s technical support department, or on the unofficial “Netscape U-FAQ” website, which listed all known bugs and features of the browser, as well as instructions regarding workarounds and fixes.

Ridlinghafer thought the company should leverage these resources and proposed the ‘Netscape Bugs Bounty Program’, which he presented to his manager, who in turn suggested that Ridlinghafer present it at the next company executive team meeting. At the next executive team meeting, which was attended by James Barksdale, Marc Andreessen and the VPS of every department including product engineering, each member was given a copy of the ‘Netscape Bugs Bounty Program’ proposal and Ridlinghafer was invited to present his idea to the Netscape Executive Team. Everyone at the meeting embraced the idea except the VP of Engineering, who did not want it to go forward believing it to be a waste of time and resources. However, the VP of Engineering was overruled and Ridlinghafer was given an initial $50k budget to run with the proposal.

On October 10 1995, Netscape launched the first technology bug bounty program for the Netscape Navigator 2.0 Beta browser.

IntroductionThank you for purchasing this book, I hope you have as much fun reading it as I didresearching and writing it.Web Hacking 101 is my first book, meant to help you get started hacking. I beganwriting this as a self-published explanation of 30 vulnerabilities, a by-product of my ownlearning. It quickly turned into so much more.My hope for the book, at the very least, is to open your eyes to the vast world of hacking.At best, I hope this will be your first step towards making the web a safer place whileearning some money doing it.

01. Open Redirect Vulnerabilities

Open Redirect Vulnerabilities Description An open redirect vulnerability occurs when a victim visits a particular URL for a given website and that website instructs the victim’s browser to visit a completely different URL, on a separate domain. For example, suppose Google had utilized the following URL to redirect users to Gmail : https://www.google.com?redirect_to=https://www.gmail.comVisiting this URL, Google would receive a GET HTTP request and use the redirect_toparameter’s value to determine where the visitor’s browser should be redirected. Afterdoing so, Google would return a 302 HTTP response, instructing the user’s browser toto make a GET request tohttps://www.gmail.com, the redirect_to parameter’s value. Now,suppose we changed the original URL to:https://www.google.com?redirect_to=https://www.attacker.comIf Google wasn’t validating that the redirect_to parameter was for one of their own legit-imate sites where they intended to send visitors (https://www.gmail.comin our example),this could be vulnerable to an open redirect and return a HTTP response instructing thevisitor’s browser to make a GET request to https://www.attacker.com.The Open Web Application Security Project (OWASP), which is a community dedicatedto application security that curates a list of the most critical security flaws in webapplications, has listed this vulnerability in their 2013 Top Ten vulnerabilities list. Openredirects exploit the trust of a given domain,https://www.google.com/in our example, tolure victims to a malicious website. This can be used in phishing attacks to trick usersinto believing they are submitting information to the trusted site, when their valuableinformation is actually going to a malicious site. This also enables attackers to distributemalware from the malicious site or steal OAuth tokens (a topic we cover in a laterchapter).When searching for these types of vulnerabilities, you’re looking for a GET request sentto the site you’re testing, with a parameter specifying a URL to redirect to.Examples1. Shopify Theme Install Open RedirectDifficulty: LowOpen Redirect Vulnerabilities14Url: app.shopify.com/services/google/themes/preview/supply–blue?domain_name=XXReport Link:https://hackerone.com/reports/1019621Date Reported: November 25, 2015Bounty Paid: $500Description:Our first example of an open redirect was found on Shopify, an e-commerce solution that allows users to set up an on-line store to sell goods. Shopify’s platform allows administrators to customize the look and feel of their stores and one of the ways todo that is by installing a new theme. As part of that functionality, Shopify previously provided a preview for the theme through URLs that included a redirect parameter. Theredirect URL was similar to the following which I’ve modified for readability:https://app.shopify.com/themes/preview/blue?domain_name=example.com/adminPart of the URL to preview the theme included a domain_name parameter at the end ofthe URL to specify another URL to redirect to. Shopify wasn’t validating the redirect URL so the parameter value could be exploited to redirect a victim tohttp://example.com/adminwhere a malicious attacker could phish the user.Take awaysNot all vulnerabilities are complex. This open redirect simply required changingthe domain_name parameter to an external site, which would have resulted ina user being redirected off-site from Shopify.2. Shopify Login Open RedirectDifficulty: MediumUrl: http://mystore.myshopify.com/account/loginReport Link:https://hackerone.com/reports/1037722Date Reported: December 6, 2015Bounty Paid: $500Description:This open redirect is similar to the first Shopify example except here, Shopify’s parameterisn’t redirecting the user to the domain specified by the URL parameter, but instead tacksthe parameter’s value onto the end of a Shopify sub-domain. Normally this would have1https://hackerone.com/reports/1019622https://hackerone.com/reports/103772Open Redirect Vulnerabilities15been used to redirect a user to a specific page on a given store. After the user has loggedinto Shopify, Shopify uses the parameter checkout_url to redirect the user. For example,if a victim visited:http://mystore.myshopify.com/account/login?checkout_url=.attacker.comthey would have been redirected to the URL:http://mystore.myshopify.com.attacker.comwhich actually isn’t a Shopify domain anymore because it ends in .attacker.com. DNSlookups use the right-most domain label,.attacker.comin this example. So when:http://mystore.myshopify.com.attacker.comis submitted for DNS lookup, it will match on attacker.com, which isn’t owned by Shopify,and not myshopify.com as Shopify would have intended.Since Shopify was combining the store URL, in this casehttp://mystore.myshopify.com, withthe checkout_url parameter, an attacker wouldn’t be able to send a victim anywherefreely. But the attacker could send a user to another domain as long as they ensured theredirect URL had the same sub-domain.TakeawaysRedirect parameters may not always be obviously labeled, since parameters willbe named differently from site to site or even within a site. In some cases youmay even find that parameters are labeled with just single characters like r=, oru=.When looking for open redirects, keep an eye out for URL parameters whichinclude the words URL, redirect, next, and so on, which may denote paths whichsites will direct users to.Additionally, if you can only control a portion of the final URL returned by the site,for example, only the checkout_url parameter value, and notice the parameter isbeing combined with a hard-coded URL on the back-end of the site, like the storeURLhttp://mystore.myshopify.com, try adding special URL characters like a period or@ to change the meaning of the URL and redirect a user to another domain.

Summary

Open Redirect Vulnerabilities17TakeawaysAs you search for vulnerabilities, take note of the services a site uses as theyeach represent new attack vectors. Here, this vulnerability was made possibleby combining HackerOne’s use of Zendesk and the known redirect they werepermitting.Additionally, as you find bugs, there will be times when the security implicationsare not readily understood by the person reading and responding to yourreport. This is why I have a chapter on Vulnerability Reports which covers detailsto include in a report, how to build relationships with companies, and otherinformation. If you do a little work upfront and respectfully explain the securityimplications in your report, it will help ensure a smoother resolution.But, even that said, there will be times when companies don’t agree with you.If that’s the case, keep digging like Mahmoud did and see if you can prove theexploit or combine it with another vulnerability to demonstrate effectiveness.SummaryOpen redirects allow a malicious attacker to redirect people unknowingly to a maliciouswebsite. Finding them, as these examples show, often requires keen observation.Redirect parameters are sometimes easy to spot with names like redirect_to=, domain_-name=, checkout_url=, and so on. Whereas other times they may have less obviousnames like r=, u=, and so on.This type of vulnerability relies on an abuse of trust, where victims are tricked into visitingan attacker’s site thinking they will be visiting a site they recognize. When you spot likelyvulnerable parameters, be sure to test them out thoroughly and add special characters,like a period, if some part of the URL is hard-coded.Additionally, the HackerOne interstitial redirect shows the importance of recognizing thetools and services websites use while you hunt for vulnerabilities and how sometimesyou have to be persistent and clearly demonstrate a vulnerability before it’s recognizedand accepted for a bounty.

02. Cross-Site Request Forgery

Description A cross-site request forgery, or CSRF attack occurs when an attacker can use an HTTP request to access a user’s information from another website, and use that information to act on the user’s behalf. This typically relies on the victim being previously authenticatedon the target website where the action is submitted, and occurs without the victimknowing the attack has happened. Here’s a basic example, which we’ll walk through:1.Bob logs into his banking website to check his balance.2.Having finished, Bob checks his Gmail account by visitinghttps://gmail.com/.3.Bob has an email with a link to an unfamiliar website and clicks the link to seewhere it leads.4.When loaded, the unfamiliar site instructs Bob’s browser to make an HTTP requestto Bob’s banking website, which transfers money from his account to the attacker’s.5.Bob’s banking website receives the HTTP request from the unfamiliar (and mali-cious) website, doesn’t have any CSRF protections, and so, processes the transfer.CookiesNow, before we jump into detail about how Bob was compromised, we need to talkabout cookies. When you visit a website that requires authentication, like a usernameand password, that site will typically store a cookie in your browser. Cookies are filescreated by websites that are stored on the user’s computer.Cookies can be used for various purposes such as for storing information like user pref-erences or the user’s history of visiting a website. To store this information, cookies canhave some attributes, which are standardized pieces of information that tell browsersabout the cookies and how they should be treated. Some attributes that a cookie couldhave include the domain, expiry date, secure, and httponly attributes.In addition to attributes, cookies can contain name/value pairs, which are made up ofan identifier and an associated value to be passed to a website (the site to pass thisinformation to is defined by the cookie’s domain attribute). A site can set any number ofcookies, each with their own purpose. For example, a site could use a session_id cookie toremember who a user is rather than have them enter their username and password forevery page they visit or action they perform. Remember that HTTP is considered statelessCross-Site Request Forgery28meaning that with every HTTP request, a website doesn’t know who a user is, so it hasto re-authenticate them for every request.So, as an example, a name/value pair in a cookie could be sessionId:123456789 and thecookie could have a domain of .site.com. This means that the user_id cookie should besent to every .site.com site a user visits, like foo.site.com, bar.site.com, http://www.site.com,and so on.The secure and httponly attributes tell browsers when and how cookies can be sent andread. These attributes don’t contain values, but instead act as flags that are either presentin the cookie or are not. When a cookie contains the secure attribute, browsers will onlysend that cookie when visiting HTTPS sites. If you visitedhttp://www.site.com/with a securecookie, your browser wouldn’t send your cookies to the site. This is to protect your privacysince HTTPS connections are encrypted and HTTP ones are not. The httponly attributetells the browser that the cookie can only be read through HTTP and HTTPS requests.This will become important when we discuss cross-site scripting in a later chapter, butfor now, know that if a cookie is httponly, browsers won’t allow any scripting languages,such as JavaScript, to read its value. A cookie without the secure attribute can be sent toa non-HTTPS site and, likewise, a cookie without httponly set can be read by a non-HTTPconnection.Lastly, the expiry date simply informs the browser of when the site will no longer considerthe cookie to be valid, so the browser should destroy it.Taking this all back to Bob, when he visits his banking site and logs in, the bank willrespond to his HTTP request with an HTTP response, which includes a cookie identifyingBob. In turn, Bob’s browser will automatically send that cookie with all other HTTPrequests to the banking website.After finishing his banking, Bob doesn’t log out when he decides to visithttps://www.gmail.com/.This is important because when you log out of a site, that site will typically send an HTTPresponse that expires your cookie. As a result, when you revisit the site, you’ll have tolog in again.When Bob visits the unknown site, he is inadvertently visiting a malicious website, whichis designed to attack his banking website. At this point, the way the malicious site exploitsthe banking site depends on whether the bank accepts GET or POST requests.CSRF with GET RequestsIf the banking site accepts GET requests, the malicious site will send the HTTP requestwith a hidden form or an <img> tag. Since the hidden form technique can be used withPOST requests as well, we’ll cover the <img> tag in this section and forms in the “CSRFwith POST Requests” section later.When an <img> tag is rendered by a browser, it will make an HTTP GET request to thesrc attribute in the tag. So, if the malicious site were to use a URL that transferred $500from Bob to Joe that looked like:https://www.bank.com/transfer?from=bob&to=joe&amount=500then a malicious image tag would use this URL as its source value, like in the followingtag:<img src=”https://www.bank.com/transfer?from=bob&to=joe&amount=500″>As a result, when Bob visits the attacker-owned site, it includes the <img> tag in its HTTPresponse and the browser then makes the HTTP GET request to the bank. The browsersends Bob’s authentication cookies to get what it thinks should be an image when in factthe bank receives the request, processes the URL in the tag’s src attribute, and processesthe transfer.For this reason, as a general web programming principle, HTTP GET requests shouldnever perform any back-end data modifying requests, like transferring money.CSRF with POST RequestsIn contrast, if the bank accepts POST requests, there are a couple of things to consider.The contents of a POST request can complicate a CSRF attack, so different techniquesneed to be used to successfully pull off an attack.The most simplistic situation involves a POST request with the content-type applica-tion/x-www-form-urlencoded or text/plain. The content-type is a header that browsersmay include when sending HTTP requests. It tells the recipient how the body of the HTTPrequest is encoded. Here’s an example of a text/plain content-type request:POST/HTTP/1.1Host:www.google.caUser-Agent:Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Content-Length:0Content-Type:text/plain;charset=UTF-8DNT:1Connection:closeThe content-type is labeled and its type is listed along with the character encoding of therequest. The content-type is important because browsers treat types differently (whichwe’ll get to in a second). Now, in this situation, it’s possible for a malicious site to createa hidden HTML form and submit it silently to the target site without a victim knowing.The form can be used to submit a POST or GET request to a URL and can even submitparameters values. Here’s an example of some malicious code:

Cross-Site Request Forgery
<iframestyle="display:none"name="csrf-frame"></iframe><formmethod='POST'action='http://bank.com/transfer.php'target="csrf-frame"id\="csrf-form"><inputtype='hidden'name='from'value='Bob'><inputtype='hidden'name='to'value='Joe'><inputtype='hidden'name='amount'value='500'><inputtype='submit'value='submit'></form><script>document.getElementById("csrf-form").submit()</script>

Here, we’re making an HTTP POST request to Bob’s bank with a form (this is denotedby the target attribute in the<form>tag). Since the attacker doesn’t want Bob to see theform, each of the<input>elements are given the type ‘hidden’ which makes them invisibleon the web page Bob sees. As the final step, the attacker includes some JavaScript insidea<script>tag to automatically submit the form when the page is loaded.The JavaScript does this by calling the getElementByID() method on the HTML documentwith the id of the form (“csrf-form”) that we set in the<form>. Like with a GET request,once the form is submitted, the browser makes the HTTP POST request to send Bob’scookies to the bank site, which invokes a transfer. Since POST requests send an HTTPresponse back for the browser, the attacker hides the response in an<iframe>with thedisplay:none attribute so Bob doesn’t see it and realize what has happened.In other scenarios, a site might expect the POST request to be submitted with the con-tent-type application/json instead. In some cases, a request that is an application/jsontype will have a CSRF token, which is a value that is submitted with the HTTP requestso that the target site can validate that the request originated from itself and not fromanother, malicious site. Sometimes the token is included in the HTTP body of the POSTrequest and, at other times, is a header like the content-type.Sending POST requests as application/json are significant because browsers will firstsend an OPTIONS HTTP request before the POST request is sent. The site then returnsa response to the OPTIONS call indicating which types of HTTP requests it accepts.The browser reads this response and then makes the actual POST HTTP request, whichin our example, would be the transfer. This work flow actually protects against someCSRF vulnerabilities because the malicious website won’t be allowed to read the HTTPOPTIONS response from the target website to know if it can send the malicious POSTrequest. This is called cross origin resource sharing (CORS).CORS is designed to restrict accessing resources, including json responses, from adomain outside of that which served the file, or is allowed by the target site. In otherwords, when CORS is used to protect a site, you can’t submit an application/json requestto call the target application, read the response and make another call, unless the targetsite allows it. In some situations, you’ll be able to work around CORS to perform a CSRFattack, as we’ll see later in this chapter Now, as mentioned, CSRF vulnerabilities can be mitigated in a number of ways so it’simportant to ensure a proper proof of concept attack before reporting them.Defenses Against CSRF AttacksThe most popular protection against CSRF is likely the CSRF token, which would berequired by the protected site when submitting potentially data altering requests (thatis, POST requests). Here, a web application (like Bob’s bank) would generate a token withtwo parts, one which Bob would receive and one which the application would retain.When Bob attempts to make transfer requests, he would have to submit his token, whichthe bank would then validate with its side of the token.These tokens aren’t always obviously named, but some potential examples of namesinclude X-CSRF-TOKEN, lia-token, rt, or form-id. The attacker wouldn’t be able to suc-cessfully submit a POST request without a valid token, and so wouldn’t be able to carryout a CSRF attack, however there CSRF tokens don’t always lead to a dead end whensearching for vulnerabilities to exploit.The obvious other way sites protect themselves is by using CORS though this isn’t foolproof as it relies on the security of browsers, ensuring proper CORS configurationswhen sites are allowed to access responses and there have been some CORS by-passvulnerabilities to this in the past. Additionally, CORS sometimes can be bypassed bychanging the content-type from application/json to application/x-www-form-urlencodedor by using a GET request instead of a POST request. Both of these depend on how thetarget site is configured.Lastly, CSRF vulnerabilities can also be avoided if a site validates the origin headersubmitted with an HTTP request, as the origin can’t be attacker-controlled and refersto the location where the request originated.

Summary

CSRF vulnerabilities represent another attack vector and may be executed without avictim even knowing or actively performing an action. Finding CSRF vulnerabilities takessome ingenuity and again, a desire to test everything.Generally, application frameworks like Ruby on Rails are increasingly protecting webforms if the site is performing POST requests, however, this isn’t the case for GETrequests, so be sure to keep an eye out for any GET HTTP calls which change server-side user data (like DELETE actions). Lastly, if you see a site is sending a CSRF token witha POST request, try changing the CSRF token value or removing it entirely to ensure theserver is validating its existence.

03. SQL Injection

DescriptionA structured query language (SQL) injection, or SQLi, occurs when a vulnerability on adatabase-backed site allows an attacker to query or otherwise attack the site’s database.SQLi attacks are often highly rewarded because they can be devastating. They can enablean attacker to manipulate or extract information or even create an administrator log infor themselves in the database.SQL DatabasesDatabases store information in records and fields contained in a collection of tables.Tables contain one or more columns and a row in a table represents a record in thedatabase.Users rely on a programming language called SQL (structured query language) to create,read, update, and delete records in the database. The user sends SQL commands(also called statements or queries) to the database and, assuming the commands areaccepted, the database interprets the statements and performs some action. PopularSQL databases include MySQL, Postgresql, MSSQL and so on. We will use MySQL for thepurposes of this chapter but the general concepts apply to all SQL databases.SQL statements are made up of keywords and functions. For example, the followingstatement tells the database to select information from the name column in the userstable, for records where the ID column is equal to 1.SELECT name FROM users WHERE id = 1;Many websites rely on databases to store information and to use that information todynamically generate content. For example, the sitehttps://www.leanpub.com/stores yourprevious orders or list of purchased ebooks in a database which you access when youlog in with your account. Your web browser queries the site’s database and generatesHTML based on the information returned.Let’s look at a theoretical example of a server’s PHP code to generate a MySQL commandafter a user visits the URLhttps://www.leanpub.com?name=yaworsk:SQL Injection78$name = $_GET[‘name’];$q = “SELECT * FROM users WHERE name = ‘$name’ “;mysql_query($query);The code uses $_GET[] to access the name value from the URL parameters specifiedbetween its brackets and stores the value in the $name variable. The parameter is thenpassed to the $q variable without any sanitization. The $q variable represents the queryto execute and fetches all data from the users table where the name column matchesthe value in the name URL parameter. The query is executed by passing the $q variableto the PHP function mysql_query.The site is expecting name to contain regular text, but if a user enters the maliciousinputtest’ OR 1=’1into the URL parameter as inhttps://www.leanpub.com?name=test’ OR 1=’1,the executed query is:$query = “SELECT * FROM users WHERE name = ‘test’ OR 1=’1′ “;Our malicious input closes the opening single quote (‘) after the value test and adds theSQL code OR1=’1to the end of the query. The hanging single quote in OR1=’1opens theclosing single quote that is hardcoded after the input. If the injected query didn’t includean opening single quote, the hanging quote would have caused SQL syntax errors, whichwould prevent the query from executing.SQL uses conditional operators like AND and OR. In this case, the SQLi modifies theWHERE clause to search for records where the name column matches test or theequation1=’1’returns true. MySQL helpfully converts treats’1’as an integer and since 1always equals 1, the condition is true and the query returns all records in the users table.However, injectingtest’ OR 1=’1won’t work when other parts of the query are sanitized.For example, you may have a query like:$name = $_GET[‘name’];$pw = mysql_real_escape_string($_GET[‘password’]);$query = “SELECT * FROM users WHERE name = ‘$name’ AND pw = ‘$pw’ “;In this case, the password parameter is also user-controlled, but properly sanitized usingthe mysql_real_escape_string function. If you use the same payload,test’ OR 1=’1as thename and your password was 12345, your statement would end up as:$query = “SELECT * FROM users WHERE name = ‘test’ OR 1=’1′ AND pw = ‘12345’ “;The query looks for all records where the name istest or 1=’1’and the password is 12345(we’ll ignore the fact that this database is storing plain text passwords, which is anotherSQL Injection79vulnerability). Because the password check uses an AND operator, our query won’t returndata unless the password for a record is 12345. This breaks our attempted SQLi, butdoesn’t stop us from trying another method of attack.We need to eliminate the password parameter, which we can do by adding;–,test’ OR1=’1;–. This injection accomplishes two things: the semicolon (;) ends the SQL statementand the two dashes (–) tell the database that the remainder of the text is a comment. Ourinjected parameter changes the query toSELECT * FROM users WHERE name = ‘test’ OR 1=’1′;.TheAND password = ‘12345’code in the statement becomes a comment, so the commandreturns all records from the table. When using – as a comment, keep in mind that MySQLrequires a space after the dashes and the remaining query otherwise it will return errorswithout executing the command.Countermeasures Against SQLiOne protection available to prevent SQLi is prepared statements, which are a databasefeature used to execute repeated queries. The specific details of prepared statementsare beyond the scope of this book, but they protect against SQLi because queries areno longer executed dynamically. The database uses the queries like templates by havingplaceholders for variables. As a result, even when users pass unsanitized data to a query,the injection can’t modify the database’s query template, which prevents SQLi.Web frameworks like Ruby on Rails, Django, Symphony, and so on also offer built inprotections to help prevent SQLi. However, they aren’t perfect and can’t prevent thevulnerability everywhere. The two simple examples of SQLi we’ve seen usually won’t workon sites built with frameworks unless the site developers didn’t follow best practicesor didn’t recognize protections weren’t automatically provided. For example, the sitehttps://www.rails-sqli.org/ maintains a list of common SQLi patterns in Rails that resultfrom developer mistakes. When testing for SQLi, your best bet is looking for olderwebsites which look custom built or used web frameworks and content managementsystems that didn’t have all the built-in protections of current systems.

Summary

SQLi can be a significant vulnerability and dangerous for a site. If an attacker were tofind a SQLi, they might be able to obtain full permissions to a site. In some situations,a SQLi can be escalated by inserting data into the database that enables administrativepermissions on the site, as in the Drupal example. When looking for SQLi vulnerabilities,keep an eye out for places where you can pass unescaped single or double quotes toa query. When you find a vulnerability, the indications that the vulnerability exists canbe subtle, such as with blind injections. You should also look for places where you canpass data to a site in unexpected ways, such as places where you can substitute arrayparameters in request data like in the Uber bug.