WyzGuys Tech Talk

URL (%) Percent Encoding , Base64 Encoding, and SQL Injection

By Bob Weiss

As we discussed in our first two articles, many of the cybersecurity certifications that I teach have content that involves the uses of encoding, code injection, directory transversal, and scripting.  These concepts can be difficult to grasp, and the exam questions can be challenging to answer correctly.  This series of articles is designed to help you understand the basic concepts, and how these get used both securely and maliciously.  I am planning to show examples to help you identify these types of use cases or exploits when they show up in an exam question.

In the first two articles of our series we covered numbering systems and character encoding.  In this episode we will look at URL encoding.  There are two main forms of URL encoding, percent (%) encoding and Base64 encoding. 

One housekeeping tip:  If you click on the images, they will expand to full size on a separate page.  You may then right click on the image and save it as a study aid.

Percent Encoding

Percent encoding is used in web uniform resource locators (URLs) to replace standard ASCII characters that are not allowed in URLs and other web applications.  There are two types of characters that are allowed in a URL, reserved and unreserved characters. See the tables below.

Reserved characters often have meanings other than part of a text string, for instance the forward slash (/) is often used as a path delimiter that separates parts on a longer web address as in this example:  https://example.com/directory/sub-directory/filename.  If for some reason I needed to use a forward slash and wanted it treated as part of the text string, I would need to replace the slash with %2F.  Similarly, spaces are allowed in Windows file names, but not in the URL, so spaces are replaced with %20.  So reserved characters are used as command codes in scripts and application code, and these are disallowed in URLs as well.  Because the percent character ( % ) serves as the indicator for percent-encoded octets, it must be percent-encoded as %25 for that octet to be used as data within a URI.

Unreserved characters do not need to be percent encoded as they simply used a characters in a text string.

Directory Traversal Using Percent Encoding

Percent encoding can be used to hide or obfuscate a directory traversal exploit.  The examples below show the unmistakable plain text string used for directory traversal

https://insecure-website.com/loadImage?filename=../../../etc/passwd  The forward slash works well when attacking Unix/Linux operating systems

or

https://insecure-website.com/loadImage?filename=..\..\..\windows\win.ini  In this example we used a back slash since we are searching a Windows file tree.

The string ../../../ or ..\..\..\ can be hidden by using the following percent encoding replacements

%2e%2e%2f or %252e%252e%252f

Next time you see a URL that includes a bunch of percent signs, you can know this is percent encoding in action.  Spend a little time decoding these URLS to learn how percent encoding is used correctly, and can be used a malicious attack, such as directory traversal

Base64 Encoding

The article in Wikipedia goes into much more depth than I can ini this article.  According to Wikipedia:

“In computer programming, Base64 is a group of binary-to-text encoding schemes that represent binary data (more specifically, a sequence of 8-bit bytes) in sequences of 24 bits that can be represented by four 6-bit Base64 digits.

Common to all binary-to-text encoding schemes, Base64 is designed to carry data stored in binary formats across channels that only reliably support text content. Base64 is particularly prevalent on the World Wide Web where one of its uses is the ability to embed image files or other binary assets inside textual assets such as HTML and CSS files.

Base64 is also widely used for sending e-mail attachments. This is required because SMTP – in its original form – was designed to transport 7-bit ASCII characters only. This encoding causes an overhead of 33–37% (33% by the encoding itself; up to 4% more by the inserted line breaks).”

URL Applications

From Wikipedia:  “Base64 encoding can be helpful when fairly lengthy identifying information is used in an HTTP environment. For example, a database persistence framework for Java objects might use Base64 encoding to encode a relatively large unique id (generally 128-bit UUIDs) into a string for use as an HTTP parameter in HTTP forms or HTTP GET URLs. Also, many applications need to encode binary data in a way that is convenient for inclusion in URLs, including in hidden web form fields, and Base64 is a convenient encoding to render them in a compact way.”

Using standard Base64 in URL requires encoding of ‘+’, ‘/’ and ‘=’ characters into special percent-encoded hexadecimal sequences (‘+’ becomes ‘%2B’, ‘/’ becomes ‘%2F’ and ‘=’ becomes ‘%3D’), which makes the string unnecessarily longer.”

Sometimes a URL will contain a log string that looks like gibberish.  Here is an example of a Base64 encoded URL that redirected a FIX NOW button on a phishing email that was discussed on a recent Friday Phish Fry.

https://u2309082.ct.sendgrid.net/ls/click?upn=HpGJr97iNoWH4wFKCT0hr1kffLmZNjVSNRrtfFhfLuarCFjuCUHUN4ofE7PplE24S-2BlcjrzjMOzKRYguF94H7g-3D-3DxTeL_SFbx6topEOS-2BGS6SqugjBqwgYiCeGFwwEr8h28hAAOgBP2fGQcs0CQreCZ4cXHiK4XFxRnqyf2bgCNQ-2Bsjn0sBCw37NPANG786LKjjhC7dq0urC1XfMDJxIhB8K7U5n0BDQ8Q3ovDcCHU4ArHrVSKx9TnB6qRnknvR8O8ctonvyBscro4-2BBqGpQYXFcaMXNRCorqlIwocqLKoQvUhwJjJA-3D-3D which was redirected to the page at https://thryv.azurefd.net/#bob@wyzguys.com

My attempts to decoding this string using the website at Base64 Decode and Encode did not show me anything useful, so perhaps this string was encoded more than once using different methods.

Lets try some other Base64 exercises.  Let’s try something shorter, like encoding my name bobbobbob to Ym9iYm9iYm9i. Notice the repetition in both the source and the encoded sample.   Let’s try somethin longer without a repeat.  the quick brown fox jumped over the lazy dog converts to dGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZWQgb3ZlciB0aGUgbGF6eSBkb2c

Let’s try encoding the Directory Traversal samples from the earlier section: ../../../ becomes Li4vLi4vLi4v. %2e%2e%2f becomes JTJlJTJlJTJmwqA

Here’s a URL that contains some percent encoding, some Base64 encoding (authkey=), and two strings that look like hexadecimal numbers (cid= and resid= sections)

https://onedrive.live.com/download?cid=77F1758961BF83C0&resid=77F1758961BF83C0%21106&authkey=ANDjDx4A6YEqSAg

This is the kind of result you can get from double encoding.  These are the sorts to text strings that may appear on some of your exam questions as examples, and you need to recognize them when you seem them in order to answer the question correctly.

SQL and other injection exploits

One of the more common exploits is command injection into SQL and other common databases.  OWASP Says: “The most famous form of injection is SQL Injection where an attacker can modify existing database queries. For more information see the SQL Injection Prevention Cheat Sheet.

But also LDAP, SOAP, XPath and REST based queries can be susceptible to injection attacks allowing for data retrieval or control bypass.

For the exam it is important to be able to recognize and stack string when you see it.  Look for uses of a truth statement such as 1=1 and the use of single and double quotes.  253-252=1 would be another example of a truth statement that is less obvious.  Here are some examples:

SELECT * FROM Users WHERE UserId = 105 OR 1=1;

SELECT UserId, Name, Password FROM Users WHERE UserId = 105 or 1=1;

SELECT * FROM Users WHERE Name =”” or “”=”” AND Pass =”” or “”=”“

SELECT * FROM Users; DROP TABLE Suppliers

These SQL injection scenarios are from OWASP.

Example Attack Scenarios

Scenario #1: An application uses untrusted data in the construction of the following vulnerable SQL call:

String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Scenario #2: Similarly, an application’s blind trust in frameworks may result in queries that are still vulnerable, (e.g., Hibernate Query Language (HQL)):

 Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

In both cases, the attacker modifies the ‘id’ parameter value in their browser to send: ‘ UNION SLEEP(10);–. For example:

 http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--

This changes the meaning of both queries to return all the records from the accounts table. More dangerous attacks could modify or delete data or even invoke stored procedures.

OWASP continues:  ” Some of the more common injections are SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP, and Expression Language (EL) or Object Graph Navigation Library (OGNL) injection. The concept is identical among all interpreters. Source code review is the best method of detecting if applications are vulnerable to injections. Automated testing of all parameters, headers, URL, cookies, JSON, SOAP, and XML data inputs is strongly encouraged. Organizations can include static (SAST), dynamic (DAST), and interactive (IAST) application security testing tools into the CI/CD pipeline to identify introduced injection flaws before production deployment.                                                                                                                 ‘

Preventing Injection Attacks

Preventing injection requires keeping data separate from commands and queries:

• The preferred option is to use a safe API, which avoids using the interpreter entirely, provides a parameterized interface, or migrates to Object Relational Mapping Tools (ORMs).
  Note: Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data or executes hostile data with EXECUTE IMMEDIATE or exec().
• Use positive server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications.
• For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter.
  Note: SQL structures such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names are dangerous. This is a common issue in report-writing software.
• Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.”

Here is an example of a SQL injection attack from my Wordfence web application firewall.

This email was sent from your website “WyzGuys Cybersecurity” by the Wordfence plugin at Friday 31st of March 2023 at 10:04:21 AM The Wordfence administrative URL for this site is: https://wyzguyscybersecurity.com/wp-admin/admin.php?page=Wordfence

The Wordfence Web Application Firewall has blocked 118 attacks over the last 10 minutes. Below is a sample of these recent attacks:

March 31, 2023 3:03pm  95.214.83.158 (United States)     Blocked for SQL Injection in POST body: ak_hp_textarea = Qmty/**/AND/**/(SELECT/**/4441/**/FROM/**/(SELECT(SLEEP(15)))rizS)–/**/HFTh

March 31, 2023 3:03pm  95.214.83.158 (United States)     Blocked for SQL Injection in POST body: ak_hp_textarea = Qmty/**/AND/**/(SELECT/**/4441/**/FROM/**/(SELECT(SLEEP(15)))rizS)

March 31, 2023 3:03pm  95.214.83.158 (United States)     Blocked for SQL Injection in POST body: ak_hp_textarea = Qmty)/**/AND/**/(SELECT/**/4441/**/FROM/**/(SELECT(SLEEP(15)))rizS)/**/AND/**/(6488=6488

March 31, 2023 3:03pm  95.214.83.158 (United States)     Blocked for SQL Injection in POST body: ak_hp_textarea = Qmty’/**/AND/**/(SELECT/**/4441/**/FROM/**/(SELECT(SLEEP(15)))rizS)/**/AND/**/’ROEh’=’ROEh

March 31, 2023 3:03pm  95.214.83.158 (United States)     Blocked for SQL Injection in POST body: ak_hp_textarea = Qmty’)/**/AND/**/(SELECT/**/4441/**/FROM/**/(SELECT(SLEEP(15)))rizS)/**/AND/**/(‘fqFS’=’fqFS

This brings us to the end of our series on URL Encoding, SQL Injection, and Directory Traversal for Cybersecurity Certification.  Hopefully I have shed a bit of light on how all of this fits together.  Good luck on certification exam, which one you are taking.  Please provide your comments, I am always looking for feedback on ways to improve these articles.