How-To

There are different types of SQL Injection attacks such as Error based, Time based and Boolean based. Each of the types of SQLi has the potential to cause a complete data breach in an organization. In this article, we are going to explore the Time Based SQL Injection attack. This type of SQL Injection utilizes the database time delays function to extract or dump the database. Let’s explore this in detail. The article is divided into below sections – What is Time Based SQL Injection Attack? SQL Delay Query Examples Time Based SQL Injection Payloads Identify if the Application is Vulnerable to Time-Based SQLi Dumping the database using Time Based SQL Injection Find MySQL Schema names using Time Based SQLi Find names of all tables under the schema in MySQL Time Based SQL Injection Prevention Techniques Conclusion What is Time Based SQL Injection Attack? We can define the Time Based SQL Injection Attack as follows – Time Based SQL Injection attack is a type of SQL Injection attack that relies on time delays in SQL query execution to infer information about database schema structure and the database contents. It is a type of inferential injection attack in which the attacker has to infer (guess, enumerate) the database structure to exploit it. Unlike in Error based SQL Injection attacks, here the application does not send any database information back to the attacker in any form. Instead, the attacker uses database time delay functions to dump the data. After executing a query that triggers a time delay on the database server, the attacker monitors the application’s response time to note whether the time delay has happened on the database server or not. If the application responds slowly as per the time delay set by an attacker, then the attacker gets a clue that the application is vulnerable to Time based SQL Injection. Let’s now first see what these SQL delay queries look like.   SQL Delay Query Examples The below tables mention the delay query syntax of different database server vendors. Database Type SQL Delay Query Description MySQL select sleep(5); Takes 5 seconds for execution. do sleep(10); Takes 10 seconds for execution. MS SQL Server wait for delay ’00:00:02’​; Takes 2 seconds for execution. PostgreSQL pg_sleep(4); Adds a sleep time of 4 seconds. For example, if you run the below query in the MySQL server, it will take 5 seconds before the query returns the version number result. select version(), sleep(10); Now, let’s understand how these time delay queries are used in time based SQL Injection payloads. Time Based SQL Injection Payloads Using the time delay queries of various database server vendors, below are some Time-based SQL Injection payloads for MySQL. ,(select * from (select(sleep(10)))a) %2c(select%20*%20from%20(select(sleep(10)))a) ‘;WAITFOR DELAY ‘0:0:30′– This GitHub repo has a comprehensive list of time-based SQL Injection payloads. Identify if the Application is Vulnerable to Time-Based SQLi Now, you can use the above time based payloads to identify if the application is vulnerable or not. For this, find just one vulnerable input parameter of the application using the below steps – Identify all input parameters of all APIs of the application using a tool like BurpSuite. Insert the time delay SQLi payloads mentioned in the above section in each parameter 1 by 1 and observe the application response time. Any parameter that triggers a slow application response, is the vulnerable one. Note: Even if just 1 parameter is vulnerable, that’s enough to dump the entire database using a Time based SQLi vulnerability. Here, we can surely say and report that the application is vulnerable to time-based SQLi. Dumping the database using Time Based SQL Injection To dump the database using a Time-based SQL injection vulnerability, you need to use conditional expressions. Let’s understand how it works under the hood. For MySQL, below is the syntax for a conditional expression. if(condition, when_true, when_false) Now, the logic to dump the data is, we have to make a guess and then conclude that whether our guess is right or wrong. We use our guesses in the ‘condition’ part and put the query delay function in the True part. If you observe a delay in application response, then it means the condition was evaluated to True. Meaning, that our guess used in the condition is correct. Now, here’s the interesting part. We will now enumerate or guess the database details piece by piece i.e. character by character. For example, if we have to guess the database has a table named ‘products’, then we will guess it, character by character i.e. p,r,o,d,u,c,t,s. So, for the first letter ‘p’, we enumerate all characters between ‘a’ to ‘z’. So, we need a total of 26 enumerations just to guess the first letter of a table. Let’s walk through this process with some real examples. Find MySQL Schema names using Time Based SQLi As mentioned before, for dumping data with time-based SQLi, you need to make guesses and try out all the guesses. For example, with the below query, we try to guess the name of 1 schema from the MySQL database. We know schema name can be read from MySQL table information_schema.SCHEMATA from column name ‘SCHEMA_NAME’ using the below query- select SCHEMA_NAME from information_schema.SCHEMATA s limit 1; Now, let’s use the query delay function and conditional expression to get the first letter of the schema name. Refer the below query – select if(substring(SCHEMA_NAME,1,1) = ‘a’, sleep(5), ”) from information_schema.SCHEMATA s limit 1; Here, we checked if the first letter of the schema name is ‘a’ or not. If it is, the query will sleep for 5 seconds. We make all 26 permutations and for 1 character we will see the query execution sleep for 5 seconds. So, this way using time-based SQL Injection, the database can be dumped. Find names of all tables under the schema in MySQL Once you identified the schema name, you can find table names using the below query and make guesses for every character using the sleep function. SELECT table_name FROM information_schema.tables limit 1; Query with sleep function – select if(substring(TABLE_NAME,1,1) = ‘a’, sleep(5), ”) from information_schema.TABLES s limit 1; Time Based SQL Injection Prevention Techniques There is no special

Path Traversal is one of the most prevalent attack techniques against web applications and is also part of the OWASP Top 10 list of web-based attacks. It is also very common and simple to exploit, with consequences ranging from file system access, information disclosure and Remote Code Execution. What is a Path Traversal attack? It is an attack technique that is intended towards accessing file system locations (files, directories) that are outside of the container on which the web application is running in. It can lead to leaking information about the system hosting the web application, such as sensitive files (config files, environment variables, files hidden from the web application etc), information (such as application source code) and even Remote Code Execution. Impact of a Path Traversal attack A Path traversal attack can have serious implications, if exploited: Leak of sensitive files and information on the filesystem Remote-code execution Creation of backdoors into the affected server How does an application become susceptible to a Path Traversal attack? Path Traversal is a consequence of improper input sanitization (at the application level) when dealing with flows that access the filesystem (such as reading of files, images and scripts). Creative constructs of payloads for those parameters can allow for traversing different locations across the filesystem, that are outside the location of the web server root. At its core, Path Traversal payloads involve parameters denoting paths to locations away from the root web application directory. The simplest payload is as below: http:///?file=../ This denotes access to one level above the base web application directory. Different types of Payloads for a Path Traversal attack Regular payloads http:///?file=../ -> Nix environmentshttp:///?file=/etc/passwd -> Absolute pathhttp:///?file=.. -> Windows environments For exploits, variations of the relative and absolute path can be picked up and can work way up the levels to reach to different areas of the filesystem.Another technique can be to fuzz the directory names in a scan to see if they exist or not. Stripped payloads http:///?file=….//….//etc/passwd This is a non-recursive traversal payload that is stripped to ../../etc/passwd Encoded payloads http:///?file=..%2F..%2F..%2Fetc%2Fpasswd%20 The above example has a URL-encoded parameter that translates to ../../../etc/passwd In addition to a single encoding level, multiple encodings can be made for more creative exploits. Payload starting from expected path http:///?file=/var/www/images/../../../etc/passwd In this case, the web application has validation in the input parameter that mandates input file to be present in the /var/www/images directory. The above payload bypasses that validation. Null-byte character These payloads are used to bypass specific file restrictions for input file (such as a requirement for the file being a PNG file). http:///?file=../../../etc/passwd%00.png The null byte at the end is discarded after validation. Basic Vulnerable App Exploit and Impact $file = $_GET[‘file’];include($file); Accessing through the following exploit GET /dirtraversal.php?file=../../../../etc/passwd Similar payloads to get the same result /dirtraversal.php?file=/etc/passwd ..%2F..%2F..%2F..%2Fetc%2Fpasswd /etc/passwd How do you prevent a Path Traversal attack? Path Traversal is a fairly simple thing to solve. At its core involves proper sanitization of user input. Preferably, do not have user input for calls to the filesystem. Check user input -> Should contain only allowed values and input containing traversal characters should be stripped off. Accept the known good input. Canonicalize user input to verify it starts with an expected base directory. A simple way to do accomplish this is to compare actual paths on the file system and determine whether there is a traversal mechanism in place. This can be done by resolving to an actual path on the filesystem and then comparing with the resolution of the actual file path. $base_path = “/opt/homebrew/var/www”;$file_path = $base_path . $file;$real_path = realpath($file_path);if($real_path === false || strpos($real_path, realpath($base_path) !== 0))echo “File not found!”;elseinclude($file_path); The above code ensures that the file path of the parameter exists in the /opt/homebrew/var/www folder, which is not the case if there is path traversal in place, resulting in the following output. Conclusion As shown, Path Traversal is a fairly common attack, being part of the OWASP Top 10 list of attacks. It is mostly caused due to developer ignorance and can cause a whole world of pain if exploited, with sensitive information disclosure and remote code execution being fairly common results of such attacks. It is fairly easy to solve and can be done with checks and balances for user input and ensuring whether filesystem access for user-input is even needed in the first place. If those measures are taken, we will be one step further in securing our web applications. At BUZZ, we have found various applications susceptible to Path Traversal attacks, which can lead to serious implications for the organizations business and reputation, if exploited. Check once or contact BUZZ experts for securing your applications and systems.

If you have detected that an application is vulnerable to SQL Injection vulnerability, then the next step to exploit the vulnerability is to know which type of SQL Injection it is. This will help you craft your SQL injection payloads as per the type. In this article, we are going to look at Error based SQL Injection which is a type of in-band SQL Injection attack. We will also provide a live demo of an error-based SQL Injection attack using Acunetix. So, let’s get started. The article will encompass the below sections. You can jump directly to any section if you want. What is error based SQL Injection? Definition of Error based SQL injection Live example of Error based SQL Injection on Acunetix Error based SQL Injection payloads How to prevent Error based SQL Injection attacks? Validate input parameters properly Use Prepared Statements Conclusion What is error based SQL Injection? An Error based SQL Injection is an in-band type of SQL Injection attack in which attackers use a single channel to fire the SQL Injection payloads and also extract the results from the same channel. An example of an in-band attack is when an attacker hits any REST API request and immediately sees the desired results in the API response. In error based SQL Injection, the attacker relies on error messages returned by the database server. The error messages help provide information about the structure of the schema and where exactly the error has occurred in the SQL query. Let’s look at the formal definition. Definition of Error based SQL injection Error based SQL Injection definition is as follows- “Error based SQL Injection is a type of SQL Injection in which the attacker can see error messages thrown by the database server when any SQL Injection payloads are fired.” The error messages contain sensitive information about the database schema, the vulnerable SQL query, and the database type. The attacker uses error information so as to accurately craft the SQL injection payloads for further penetration into the victim’s database system. It will be clearer to you when you see some live examples of error based SQL Injection in the next section. Live example of Error based SQL Injection on Acunetix Acunetix hosts a vulnerable web application online for testing purposes. It is freely accessible to all. The aim of the application is to demonstrate some of the severe web application vulnerabilities. You can access the Acunetix vulnerable web application here. There are many vulnerabilities in this application. However, we will only demonstrate the Error based SQL Injection. To do this, you need to navigate as below : Click on the Categories menu -> Click on any category displayed -> You will see posters in the category. Now observe the URL in the address bar. It accepts a category ID as an input parameter as highlighted below. http://testphp.vulnweb.com/listproducts.php?cat=1 This parameter is vulnerable to Error-based SQL Injection. Now, to test for SQL Injection on this parameter, just append a single quote (‘) in the URL right after the value of the category ID. The resulting URL may be as below (You can copy and paste in address bar): http://testphp.vulnweb.com/listproducts.php?cat=1′ Now as soon as you hit enter, instead of posters in the category you will see an Error message. Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ”’ at line 1 Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean given in /hj/var/www/listproducts.php on line 74 This error message is thrown by the MySQL database server. This database-side error message is a first clue to an attacker that the entered parameter value is reaching to query as it is entered (along with possibly any junk characters entered). We have highlighted the sensitive information in the above log. It clearly shows the underlying database is of type MySQL and there is an error at line 1. You can now play around with parameter values and try to inject different variants of SQL Injection payloads from the payload list in the next section. Error based SQL Injection payloads Now we know the parameter named ‘cat‘ is vulnerable to Error based SQL Injection, we can now embed various SQLi payloads. Let’s inject the payloads now – SQLi Payload Direct link to hit (Including payload) 1 OR 1=1 Link – Shows posters from all categories 1 AND (SELECT 2839 FROM (SELECT(SLEEP(10)))DtDN) Link – Make database thread to sleep for 10 seconds For a full list of thousands of Error-based SQL Injection payloads, visit this GitHub repository. How to prevent Error based SQL Injection? As with any SQL Injection attack, the attacker tries to exploit the input parameters in the application and injects the SQLi payload into the same. This is also applicable to error based SQL Injection attacks. Below we list down the 2 important prevention techniques. Validate input parameters properly As in the above Acunetix application’s example, the vulnerable parameter is ‘cat‘. It is a numeric field representing the category ID. Hence, on the server side we need to put a validation to check whether provided category ID is really an integer or not. Use PreparedStatements Do not create the SQL query using the string concatenation technique. You need to use PreparedStatements so that the query parameters do not alter the structure of the query being fired. Conclusion Out of all types of SQL Injection attacks, the error based SQL Injection is the most severe. It is severe because of the reduced turnaround time in seeing the results. And hence in a few minutes of time, the attacker will be able to download the entire database of victim applications. BUZZ is an expert player in doing security assessments of SMBs and startups. We have found many instances of Error-based SQL Injection vulnerability in SMB’s internet-facing systems. Remember, a single vulnerable parameter is a doorway for an attacker to download the entire database. The endpoints look safe to the open eyes but upon security assessment, the full database gets exposed. Do your application’s endpoints also look

In almost all cyber-attacks, hackers exploit the security bugs (aka. vulnerability) in the victim’s networks, machines, or software installed. One such particularly severe vulnerability is “SQL Injection”. This vulnerability is of such significance that attackers can dump entire databases of victims. This might lead to the forced closure of the organization. In this article, you will understand what is SQL Injection attack and what causes SQL Injection attacks to happen. We will also explain a few of the basic prevention techniques for SQL Injection attacks. So, let’s get started. This article is divided into below sections. You can jump directly to any section. Definition of SQL Injection attack How does SQL Injection attack work? Demonstration of SQL Injection Prevention of SQL Injection attack Prevention Technique 1: Use PreparedStatement with parameters Prevention Technique 2: Validate input parameters Does SQL injection still work in 2023? Conclusion Definition of SQL Injection attack SQL Injection attack is an injection type of attack in which an attacker injects malicious SQL statements (aka payloads) in the user-provided input fields of the application. These input fields are then used as is to prepare SQL statements that will be executed on the database server. In other words, in an SQL Injection attack, an attacker can execute unauthorized SQL statements on the victim’s database through the application’s input fields. Using this attack, an attacker can get a complete hold of the victim’s database. The database under attack has no way of knowing whether the SQL statement being executed is a normal SQL statement triggered by the application or is a manipulated SQL statement executed as a part of an SQL injection attack by hackers. Let’s now understand how this attack works internally and what are the main causes of the attack. How does an SQL Injection attack work? Now, we will explain how SQL injection attack works with an example that you can relate to your often, daily required action i.e. a Login form. Consider the below example of a “Login Form” SQL Injection attack. As can be seen, the user needs to enter his username and password in order to log in. Below are the contents of the users table containing the username and password to be checked (Although it’s a bad table design where passwords are kept in unencrypted form, let’s keep the table super simple to understand the SQLi attack) Once the user clicks on the “LOG IN” button, an API call to the backend server will be made with a payload containing the entered username & password. We directly look at server-side logic that validates entered credentials with the credentials in the database table. public static void main(String[] args) { String username = “john”; String password = “John@123”; //password = “John@1231′ OR ‘1’=’1”; // SQLi payload input try { int userid = validateCredentialsAndFetchUserId(username, password); System.out.println(“User is found. User Id is :” + userid); } catch (InvalidUserException e) { System.out.println(“Wrong username or password entered. No user found.”); } } private static int validateCredentialsAndFetchUserId(String username, String password) { Connection con = null; Statement st = null; ResultSet resultSet = null; try { Class.forName(“com.mysql.cj.jdbc.Driver”); con = DriverManager.getConnection(“jdbc:mysql://localhost:3306/mydb”, “mydbuser”, “Mydbpassword@123”); st = con.createStatement(); // Below SQL fetches the user with given username and password combination String sql = “select * from users where username='” + username + “‘ and password='” + password + “‘”; System.out.println(“SQL to be fired :”+sql); resultSet = st.executeQuery(sql); if (resultSet.next()) { // We got the results. This means the user with given userid and password exist. // There can be max 1 record with given combination. // Now just return user id of the first result. return resultSet.getInt(“userid”); } else { throw new InvalidUserException(“Invalid user with username :” + username); } In the above code, we are building an SQL query in the below form. select * from users where username=’john’ and password=’John@123′ If this query returns at least 1 result, then it means entered credentials exist in the database and the user is valid. The query is built using the string concatenation technique as below- String sql = “select * from users where username='” + username + “‘ and password='” + password + “‘”; This code snippet is vulnerable to SQL Injection attacks. It is an example of Error based SQL Injection. Here, the user-provided input fields are passed as is to build a database query using the string concatenation technique. An attacker can embed an actual SQL statement in any of the input fields and our code will concatenate the user’s input as is to the final SQL query to be executed on the database server. Let’s understand with some example input test cases. Note, that we have added some debug logs (using system.out). Demonstration of SQL Injection The test case with valid credentials For username=”john” and password=”John@123″, below is the output. SQL to be fired:- select * from users where username=’john’ and password=’John@123′ User is found. User Id is: 100 The test case with “invalid” credentials For username=”john” and password=”John@123456″, below is the output. SQL to be fired:- select * from users where username=’john’ and password=’John@123456′ Wrong username or password entered. No user found. This is working well. As a developer, you will be happy that the program is working well as you have checked both positive and negative test cases. Now, the time is for some impressive part, the hacker’s test case – The hacker’s test case For username=”john” and password=”John@1231′ OR ‘1’=’1″, below is the output. Observe the quotes in the password. They are important so that a valid SQL statement is generated in the backend. SQL to be fired:- select * from users where username=’john’ and password=’John@1231′ OR ‘1’=’1′ User is found. User Id is: 100 As you can see, the hacker has entered the wrong password of the user (but injected the SQL injection payload in the password field) and is able to fetch the user ID (i.e. bypassed authentication). The SQLi payload used in the above test case is John@1231′ OR ‘1’=’1. Prevention of SQL Injection attack As you have

In the intricate landscape of API security, Broken Authentication emerges as a critical vulnerability, potentially allowing unauthorized users to gain illegitimate access to sensitive data and functionalities. This guide will delve into Broken Authentication, explore its various manifestations, and provide strategies, along with code samples, to fortify APIs against it. Understanding Broken Authentication Broken Authentication transpires when issues in the way APIs authenticate users lead to unauthorized access. This can stem from various factors, such as weak tokens, lack of token expiration, and misconfigured JSON Web Tokens (JWTs). Scenarios and Examples of Broken API Authentication Let’s explore various scenarios where weak or none API authentication plays a role, illustrating how this vulnerability can manifest in real-world API interactions and potentially be exploited by malicious actors. Weak Tokens Predictable Tokens: Utilizing tokens that are easily predictable or decipherable, enabling attackers to impersonate legitimate users. Lack of Token Expiration Stale Tokens: Allowing tokens to remain valid indefinitely, providing continuous access even if they are compromised. Misconfigured JWTs Insecure Algorithms: Employing insecure algorithms, like ‘none’, in JWTs, which attackers can exploit to forge tokens. Credential Stuffing Using Breached Credentials: Attackers utilize credentials obtained from breaches to gain unauthorized access. Consequences of Broken API Authentication Now, that we know scenarios where this plays out – let’s delve into the potentially devastating impacts that can unfold in the wake of an API authentication breach. Unauthorized Access: Attackers can access and manipulate sensitive data and functionalities. Data Breach: Sensitive user data can be exposed to malicious actors. Identity Theft: Attackers can impersonate legitimate users and perform malicious activities. Business Logic Abuse: Attackers can exploit business logic to perform unauthorized operations. Mitigation Strategies Against Broken Authentication Fear not, there is a toolkit to safeguard your APIs from the insidious threat of authentication vulnerabilities. More below. Employ Strong Tokens – Utilize tokens with high entropy and ensure they are securely generated. – Implement token blacklisting mechanisms to invalidate tokens when necessary. Implement Token Expiration – Ensure that tokens expire after a certain period and require users to re-authenticate. – Implement refresh tokens securely to allow users to obtain a new access token without logging in again. Configure JWTs Securely – Ensure that JWTs are configured to use secure algorithms, such as RS256. – Validate the ‘alg’ field in JWT headers to prevent algorithm switching attacks. Prevent Credential Stuffing – Implement account lockout mechanisms after a certain number of failed login attempts. – Employ CAPTCHAs to prevent automated login attempts. Differentiating Authentication from Authorization Authentication verifies the identity of a user, ensuring that the user is who they claim to be. Authorization verifies the permissions of an authenticated user, ensuring they have the right to perform a requested action. Ensure that authentication is performed before authorization in your API logic to ensure secure access control. Conclusion Developers must ensure APIs are not only robust but also impenetrable. Right authentication is paramount to safeguarding sensitive data, restricting usage to authorized personnel, and protecting user trust in our applications. In a world of growing data breaches, proactive API security may set a platform apart. Always know who is accessing the APIs! For more insights, tutorials, and a community of security-aware developers, visit BUZZ. Together, we will make security accessible to all!

Imagine asking your team, “Are we developing according to security standards? Are we secure?” and receiving a confident “Of course” in return. The truth behind such assurances often surfaces during a security breach, a compliance audit, a Vulnerability Assessment and Penetration Testing (VAPT), or when a bug bounty hunter reveals your own data and access vulnerabilities. The aftermath can be financially and reputationally damaging, with recovery potentially being a long and expensive journey. While cybersecurity is a vast domain, let’s explore the top 5 pivotal questions to initiate your journey toward a secure business environment, encouraging you to dig deeper as you explore. Top 5 Security Questions #1. Is Our Data Safe? #2. Who Has Access? #3. What If We Get Hacked? #4. Are Our Systems Updated? #5. Are 3rd Party Tools Secure? #1. Is Our Data Safe? This question probes the measures in place to safeguard your data against unauthorized access and potential breaches. Beware of Responses Like – “We use default encryption settings.” “We don’t need MFA, passwords are strong enough.” “We store backups on the same network.” Why Be Wary? Default encryption settings may not align with your specific security needs. Sole reliance on passwords, even strong ones, leaves a vulnerability window, and storing backups on the same network poses a risk of losing them during network breaches. What Can You Do? Advanced Encryption: Utilize a robust secret code for your data, making it difficult for unauthorized parties to decipher. Multi-Factor Authentication (MFA): Implement a two-step verification process, enhancing security by requiring an additional verification step after entering the password. Separate Backup Storage: Ensure backups are stored in a different, secure location to safeguard them against network breaches. #2. Who Has Access? This pertains to the management and monitoring of who can access your data and systems. Beware of Responses Like – “We don’t differentiate access levels.” “We don’t regularly review access lists.” “We don’t track data access or modifications.” Why Be Wary? Lack of differentiated access means individuals may have unnecessary access to sensitive data. Without regular reviews and tracking, unauthorized or outdated access may go unnoticed. What Can You Do? Role-Based Access: Assign access based on roles to ensure individuals access only the data relevant to their work. Periodic Access Reviews: Regularly check and update access lists to prevent unauthorized access. Data Access Tracking: Utilize tools that log and alert for any unauthorized data access or modifications. #3. What If We Get Hacked? This explores your preparedness and response plan in the event of a cybersecurity incident. Beware of Responses Like – “We’ll know when customers complain.” “We’ll just restore from a backup.” “We’ll change passwords and it’ll be fine.” Why Be Wary? Relying on customer complaints as a breach alert system is reactive and damaging. Sole reliance on backups and password changes post-breach may not address the root cause or extent of the breach. What Can You Do? Incident Response Plan: Create a detailed plan outlining actions during a breach, ensuring a quick and organized response. Continuous Monitoring: Employ security tools that continuously check your systems for unusual activities and provide alerts for any potential breaches. Backup and Restore Strategy: Ensure your backup system can quickly restore data in case of loss, ensuring business continuity. #4. Are Our Systems Updated? This questions the regularity and methodology of updating your systems and software. Beware of Responses Like – “We update when the system prompts us.” “We avoid updates to prevent downtime.” “We update manually when we remember.” Why Be Wary? Infrequent or manual updates can leave systems vulnerable to known issues that have been patched in newer versions. What Can You Do? Automated Updates: Enable automatic updates to ensure you’re always using the latest, most secure versions. Scheduled Update Checks: Regularly check for updates even with automation to ensure all systems and software are up-to-date. Rollback Plan: Have a plan to revert systems back to a previous state in case an update causes issues, ensuring minimal disruption to operations. #5. Are 3rd Party Tools Secure? This assesses the security vetting process for third-party tools and services utilized by your business. Beware of Responses Like – “We assume popular tools are secure.” “We haven’t read their security documentation.” “We don’t have a dedicated team to assess tools.” Why Be Wary? Assumptions about security can be dangerous. Lack of knowledge about a tool’s security features and not having dedicated personnel for assessment can expose you to risks. What Can You Do? Security Assessments: Thoroughly check third-party tools for security features and any history of breaches before use. Understanding Security Documentation: Ensure at least one team member understands the tool’s security setup and can ensure it aligns with your needs. Dedicated Personnel: Consider having a team member or external consultant focusing on assessing and ensuring the security of the tools and platforms you use. To Conclude Embarking on a cybersecurity journey requires a meticulous approach to questioning and understanding the security posture of your business. While the above questions serve as a starting point, the path to cybersecurity is continuous and evolving. Ensure that your questions are specific, your skepticism healthy, and your approach proactive to safeguard your business in the digital realm. Ask Specific Security Questions! For more insights, tutorials, and a community of security-aware developers, visit BUZZ. Together, we will make security accessible to all!

Despite advancements in cybersecurity, SQL injection vulnerabilities remain a significant concern, securing a spot in the OWASP Top 10 vulnerabilities list in 2023. Recent data breaches have further highlighted the importance of addressing this vulnerability. For hackers, it’s a goldmine; for penetration testers and developers, it’s a must-do. Enter SQLMap—a powerful tool designed to detect and exploit SQL injection vulnerabilities. Not only does it identify potential weak spots, but it also aids in extracting data from vulnerable endpoints. Whether you’re a seasoned cybersecurity professional or a newbie developer, understanding how to use SQLMap is crucial. In this guide, we’ll walk you through the process of setting up SQLMap on a Windows machine, specifically Windows 10. By the end, you’ll be equipped to run your first SQL injection test using SQLMap. Here’s what we’ll cover: Downloading SQLMap Prerequisites on Windows: Setting up the right environment. Downloading SQLMap Utility on Windows: Getting the tool ready. Running Your First Test: Diving into SQL injection testing. What is SQLMap? SQLMap is an open-source software available on github. It is written in python and can run on any operating system. In this article we will set up SQLMap on a Windows machine using Windows 10 operating system. So with this little introduction of SQLMap and SQLInjection, let’s dive in! Downloading SQLMap Prerequisites on Windows Before diving into the SQLMap installation, it’s crucial to ensure your system has the necessary environment set up. For SQLMap, this primarily means having Python installed. Here’s what you need to know: #1. Python Compatibility SQLMap is versatile and works with multiple Python versions. While it’s compatible with Python 2.6 and 2.7, the latest SQLMap version is optimized for Python 3. #2. Checking Your Python Version If you’re unsure whether you have Python installed or want to check its version, open your command prompt or terminal and type python –version. #3. Downloading Python For newcomers or those looking to update, we recommend Python 3 for the best experience. Download Python 3 from the official website. As of this article’s publication, Python 3.11 is the latest version, fully compatible with the most recent SQLMap release. With Python ready, you’re one step closer to harnessing the power of SQLMap on your Windows machine! Installing SQLMap on Windows SQLMap, a favorite among developers and cybersecurity experts, stands out for its simplicity and efficiency. Written in Python, it’s distributed as a library, eliminating the need for a cumbersome installation process. Instead, you can run SQLMap as you would any Python program. #1. Accessing the SQLMap Repository Visit the official SQLMap GitHub repository. Familiarize yourself with the repository’s layout. This is where all the magic happens! #2. Downloading SQLMap Locate the “Code” button on the repository’s top right corner and click on it. From the dropdown menu, select “Download ZIP”. For a visual guide, refer to the screenshot below: #3. Setting Up SQLMap Once your download is complete, extract the SQLMap ZIP file to a folder of your preference. After extraction, your folder should resemble the structure shown in the following screenshot: And voilà! SQLMap is now ready for action. Remember, no special configurations are needed to start using SQLMap. However, ensure Python is set up correctly to avoid any hiccups. Your First SQL Injection Test with SQLMap on Windows Having set up SQLMap, you’re all set to check out SQL Injection vulnerabilities. Follow these steps to run your first test – #1. Setting the Stage Launch the command prompt and navigate to the directory where you extracted SQLMap. #2. Initiating SQLMap Enter the command python sqlmap.py. If everything’s set up correctly, you should see the following output: #3. Testing for SQL Injection For this guide, we’ll use vulnweb as our test endpoint. To test the ‘cat’ URL parameter for SQL Injection, simply run: python sqlmap.py http://testphp.vulnweb.com/listproducts.php?cat=1 SQLMap’s intuitive design will automatically detect vulnerabilities, as shown below: Note: Always ensure you have permission to test the target system. Ethical hacking is about improving security, not exploiting it. Conclusion SQLMap’s capabilities extend far beyond the basics covered in this guide. For a deeper dive into its features and functionalities, explore its official GitHub usage page. We hope this guide has empowered you with the tools and knowledge to confidently set up SQLMap on Windows and embark on your SQL Injection testing journey. Remember, with great power comes great responsibility. Always prioritize ethical hacking practices. Use SQLMap to tackle and triumph over injection vulnerabilities. For more insights, tutorials, and a community of security-aware developers, visit BUZZ. Together, we will make security accessible to all!

In an era where cybersecurity threats are ever-evolving, having the right tools in your arsenal is paramount. Enter Burp Suite—a versatile tool often likened to a Swiss army knife for penetration testers. From initial reconnaissance to asset discovery and manual endpoint testing, Burp Suite plays a pivotal role in ensuring robust security measures. However, for those new to the world of penetration testing, setting up Burp Suite can seem daunting. Fear not! This guide is tailored to help beginners seamlessly set up Burp Suite on Windows 10 and 11 without spending a dime. Here’s a sneak peek into what we’ll cover: Download and Install: Getting the Burp Suite set up on your machine. Configuration: Making Burp Suite play nice with Google Chrome. First Interception: Preparing to intercept your inaugural request. With the right guidance, you’ll be well on your way to mastering Burp Suite and enhancing your cybersecurity skills. What is Burp Suite? Developed by PortSwigger, Burp Suite is an integrated platform tailored for effective penetration testing and vulnerability assessment of web applications. With capabilities ranging from intercepting browser traffic to scanning for vulnerabilities and automating custom attacks, Burp Suite offers a comprehensive toolkit for various stages of the testing process. Its user-friendly interface, combined with powerful features, has made it a favorite among both novices and seasoned security professionals. Whether you’re aiming to identify security loopholes in a web application or delve into the intricacies of web traffic, Burp Suite is the go-to tool that promises precision, efficiency, and reliability. So with this little introduction of Burp Suite, let’s get you set up! Setup Burp Suite on Windows Setting up Burp Suite might seem daunting at first, but with the right guidance, it becomes a straightforward process. Here’s a step-by-step guide to getting Burp Suite up and running on your Windows machine: 1. Download and Install Navigate to Portswigger’s Burp Suite Community edition download page and select the appropriate version for Windows. Follow the prompts to complete the installation. 2. Configuration Ensure Burp Suite and Google Chrome are configured to work seamlessly together. 3. First Interception With everything set up, you’re now ready to intercept your first request. 1. Download Burp Suite Installation In order to download Burp Suite for free, please follow these steps: Hit the below link to go to Portswigger’s Burp Suite Community edition download page – https://portswigger.net/burp/releases/community/latest On the downloads page, select the Burp Community Edition & operating system as Windows in the dropdown selections. Please refer to the screenshot below. Click on Download. The installation setup will start downloading. Once the download is complete, double-click the installer file and follow the prompts to complete the installation. 2. Configure Burp Suite to work with Google Chrome #2A. Turn on Intercept in Burp Suite Launch the Burp Suite Community Edition from the Start Menu. Proceed with ‘Temporary project in memory” option as in the screenshot below. On the next screen, continue with the first option “Use Burp Defaults” and click on ‘Start Burp”. Burp Suite will start. Go to its “Proxy” tab as in the screenshot below. Now, inside the Proxy tab, go to the “Proxy Settings” subtab and verify the default proxy settings such as IP and port number. The default proxy address of Burp Suite is 127.0.0.1:8080. Now, we need to use this proxy address in System settings in the next step. #2B. Change System Proxy settings to point to Burp Proxy address Open settings in Google Chrome Or go to link : chrome://settings/system Click on the option “Open your computer’s proxy settings” as below. It will open System Proxy Settings as below: Make sure that Automatically detect settings and Use setup script are Off. Set Use a proxy server to On. Enter your Burp Proxy listener address in the Address field (by default, 127.0.0.1). Enter your Burp Proxy listener port in the Port field (by default, 8080). Make sure that Don’t use the proxy server for local (intranet) addresses is unchecked. The final setting should look like the below screenshot. Click Save. #2C. Install Burp Suite’s CA Certificate in Chrome If the web application under test is using https, then you need to use Burp provided CA certificate in Google Chrome so that Burp Suite can decipher the https traffic from the application and also cipher it again so that it can forward it to the application’s server. Setting up the CA certificate of Burp Suite is a 2-step process viz. Export the CA certificate from Burp Suite Import the certificate into Google Chrome Export the CA certificate from Burp Suite Make sure that Burp Suite is running. Visit http://burpsuite in Chrome. On the “Welcome to Burp Suite Community Edition” page, click CA Certificate to download your unique Burp CA certificate. Make a note of where you save the CA certificate. Import the certificate into Google Chrome Open Chrome and go to the Customise (hamburger) menu. Select Settings and open the “Privacy and security” menu. From the Security menu, select “Manage certificates”. Select the “Trusted Root Certification Authorities” tab and click Import. Click Next, and browse to the CA certificate that you exported from Burp Suite. Click open. Make sure that the Trusted Root Certification Authorities certificate store is selected and click Next. Click Finish. Now restart chrome. 3. Start intercepting the requests in Burp Suite So far, we have started the proxy in Burp Suite and used it as our System proxy. Additionally, we have set Google chrome to forward the https traffic to burp suite and burp suite CA certificate will take care of cipher and deciphering of the https traffic. Conclusion With Burp Suite now set up on your Windows machine, you’re equipped to delve into the world of web security testing. Open any website in Google Chrome, and you’ll see requests being intercepted in the Burp Suite’s Proxy tab. We hope this guide has been insightful and has streamlined your Burp Suite setup process on Windows 10 and 11. Think like a hacker, secure like a pro with

In the vast landscape of web application vulnerabilities, input fields often emerge as unsuspecting culprits. If left unchecked, the data for user interaction can become the Achilles’ heel of your application’s security. This guide is dedicated to developers and engineers, aiming to shed light on input field vulnerabilities and providing robust solutions. Read on to find out more. The Vulnerabilities of Input Fields SQL Injection(SQLi) Attackers manipulate input to run malicious SQL queries. The following bypasses authentication by rendering the SQL statement always true. SELECT*FROM users WHERE username=”OR’1’=’1′; — AND password=” OR ‘1’=’1′; To identify – Monitor logs for unusual patterns, especially multiple failed logins followed by an unexplained success. Cross Site Scripting(XSS) Harmful scripts are injected, and executed by unsuspecting users. The following script showcases the execution of injected malicious code. To identify – Watch for unexpected script executions or user reports of strange behaviors. Server Side Includes (SSI) Injection User input is processed as SSI directives, leading to unauthorized server actions. The following directive, when processed, reveals the server’s root directory. To identify – Monitor for unexpected server behaviors or outputs in web pages. Command Injection Malicious commands are executed via input fields. The following demonstrates the execution of arbitrary system commands. ; ls -alh To identify – Review system logs for unexpected command executions. Input Field Vulnerabilities- Potential Causes Lack of Input Validation Blindly trusting user inputs, be it from a web form or an API payload. Direct SQL Query Execution Crafting SQL queries by string concatenation with user inputs is like tightrope walking without a safety harness. Automate Discovery of Input Field Vulnerabilities In the age of automation, manual checks aren’t enough. Here’s how to automate the discovery process: Automated Input Field Scanners Tools like OWASP ZAP and Burp Suite can be tailored to target input fields. They fuzz input fields with various payloads to detect vulnerabilities. Custom Scripts for Input Field Testing Write scripts to target input fields, sending malicious payloads to test for vulnerabilities. import requests TARGET_URL = ‘http://example.com/login’ PAYLOADS = [“‘ OR ‘1’=’1′; — “, “‘ OR ‘a’=’a”, “‘; DROP TABLE users; –“] for payload in PAYLOADS: response = requests.post(TARGET_URL, data={‘input_field_name’: payload}) if ‘unexpected response’ in response.text: print(f”Potential vulnerability detected with payload: {payload}”) Automated Input Validation Tests Integrate unit and integration tests into your CI/CD pipeline to test input validation logic. Protecting Against Input Validation Vulnerabilities General: Always validate and sanitize user input. Implement a principle of least privilege. SQL Injection: Use prepared statements and ORM (Object-Relational Mapping) tools. XSS: Sanitize user input and implement a Content Security Policy (CSP). Command Injection: Avoid using user input directly in system commands. If necessary, use strict whitelists of allowed input. SSI Injection: Disable SSI for pages that don’t require it. Ensure user input is never processed as an SSI directive. Conclusion In web application development, input fields are both vital for user engagement and security risks. In addition to building functioning apps, developers must build secure web applications. We protect our applications and build user confidence by analyzing input field vulnerabilities and taking proactive measures. If you remember one thing –Validate, Validate, Validate Input Data! For more insights, tutorials, and a community of security-aware developers, visit BUZZ. Together, we will make security accessible to all!

APIs have become the cornerstone of contemporary software, facilitating dynamic interactions and seamless data exchanges. While developers harness APIs to craft enriched user experiences, it’s imperative that these interfaces are not only efficient but also secured against vulnerabilities. One such subtle yet pervasive vulnerability is IDOR, or Insecure Direct Object References. This vulnerability poses a significant threat, potentially granting unauthorized data access and jeopardizing both businesses and their users. Read on to find out more on how to protect APIs from IDOR. What Is An Insecure Direct Object Reference(IDOR)? Insecure Direct Object References occur when an API endpoint exposes a reference to an internal implementation object. Attackers can manipulate these references to gain unauthorized access to data. Examples of IDOR The following examples can be applied to similar situations. User Profile Access An API endpoint is designed to fetch user profiles and if proper checks aren’t in place, an attacker could modify the userId parameter to view profiles of other users. GET /api/users/{userId} Order Details Access Consider an e-commerce platform where users can view their order details where an attacker could iterate through different orderId values to fetch details of orders placed by other users. GET /api/orders/{orderId} File Retrieval If an application allows users to upload and retrieve files with an endpoint and without proper authorization checks, an attacker could potentially access files uploaded by other users. GET /api/files/{fileId} What is the Impact of an IDOR breach? Data Breach The most direct consequence is unauthorized data access. Sensitive user data like personal details, financial information, or business-critical data can be exposed. Data Manipulation In some cases, IDOR might not just be used to view data but also to modify it. For instance, changing the parameters in a PUT or POST request can lead to data being altered. Reputation Damage Data breaches, especially those involving user data, can severely damage the reputation of a business. It can lead to loss of trust, users, and potential legal consequences. Financial Loss Especially in scenarios where financial transactions are involved, IDOR can lead to monetary losses. How Can You Protect APIs From IDOR? These few simple steps can help protect against an IDOR attack. Always Authenticate and Authorize Ensure that every API request is both authenticated (the user is who they claim to be) and authorized (the user has permission to perform the requested action). app.get(‘/api/orders/:orderId’, (req, res) => { let orderId = req.params.orderId; if (auth.isUserAuthenticated() && auth.isOrderOwnedByUser(orderId)) { database.getOrder(orderId); } else { res.status(403).send(‘Unauthorized’); } }); Avoid Exposing Direct Object References Instead of using database IDs, consider using UUIDs or other non-sequential identifiers that are harder to guess. Implement Rate Limiting This can prevent attackers from easily iterating through different IDs to find valid ones. Use Proper HTTP Verbs Ensure that data-changing operations like PUT, POST, or DELETE are protected against unauthorized access. Logging and Monitoring Keep detailed logs of API access patterns. Unusual patterns, like rapid sequential ID access, can be flagged for review. Regular Audits Periodically review and test your API endpoints for vulnerabilities. Tools like OWASP ZAP can help automate some of these checks. Conclusion Developers must ensure APIs are secure and resilient. By preventing IDOR vulnerabilities, we preserve sensitive data and maintain user trust in our apps. In a world of growing data breaches, proactive API security may set a platform apart. Check your APIs often. For more insights, tutorials, and a community of security-aware developers, visit BUZZ. Together, we will make security accessible to all!