Shield Security Plugin Update: Addressing CVE-2023-6989

While looking into Shield Security Plugin Update: Addressing CVE-2023-6989, in the ever-evolving landscape of web security, the vigilance of developers and security professionals plays a crucial role in safeguarding digital assets. Among the myriad vulnerabilities that pose threats to web applications, Local File Inclusion (LFI) stands out for its potential to compromise server integrity and user data.

Recently, the cybersecurity community turned its attention to a critical issue identified within the Shield Security plugin for WordPress, a widely trusted tool designed to bolster website defenses against such vulnerabilities. This discussion embarks on a comprehensive exploration of CVE-2023-6989, an LFI vulnerability that was meticulously identified and subsequently patched in the Shield Security plugin, shedding light on the intricacies of the vulnerability, the swift response by the development team, and the broader implications for web security.


represents a pivotal moment in the continuous battle against cyber threats, underscoring the critical lesson for the digital realm: the importance of relentless scrutiny and rapid response in the face of security vulnerabilities. As we delve deeper into the technical details of CVE-2023-6989, the measures taken to patch it, and the best practices for securing WordPress plugins, our goal is to equip developers, administrators, and cybersecurity enthusiasts with the knowledge and tools needed to fortify their digital environments.

Through this exploration, we aim to foster a deeper understanding of the challenges and responsibilities inherent in maintaining the security of web applications in today’s interconnected world, highlighting the collaborative effort required to navigate these complex challenges successfully.

In a deeper exploration of the CVE-2023-6989 vulnerability within the Shield Security plugin for WordPress, it’s crucial to understand both the technical and practical implications for website administrators and the broader WordPress community. This incident not only highlights the need for rapid response mechanisms but also underlines the importance of a layered security strategy for web assets.

Understanding CVE-2023-6989

CVE-2023-6989 exposed a critical security flaw in a widely used WordPress security plugin, affecting over 50,000 sites. The vulnerability allowed for Local File Inclusion (LFI), a type of exploit where an attacker can include files on a server through the web browser. This could potentially allow attackers to execute arbitrary PHP code, leading to unauthorized access to or control over a website.

The Discovery and Response

The discovery of this vulnerability by a researcher and its report through the Wordfence Bug Bounty Program demonstrate the effectiveness of community-driven security initiatives. The prompt action taken by Shield Security’s team to release a patch within days highlights the critical role of vendor responsiveness in mitigating potential threats. the vulnerable version of Shield Security

The CVE-2023-6989 vulnerability, identified in Shield Security version 18.5.9, has been addressed in the current version 18.5.10, highlighting the importance of timely updates for maintaining web asset security updates.

Technical Breakdown

The vulnerability stemmed from the plugin’s inadequate file path sanitization. This oversight allowed attackers to exploit the plugin’s template management system, which processes .twig, .php, or .html files, to include arbitrary PHP files. Such vulnerabilities underscore the necessity of rigorous security practices in plugin development, including thorough input validation and sanitization.

Implications for WordPress Site Owners

For WordPress site owners, this incident serves as a clear reminder of the importance of maintaining up-to-date plugins and themes. Regular updates are essential for security because they frequently include patches for flaws that attackers could exploit.

Broader Lessons for the WordPress Ecosystem

Community Vigilance: The discovery of CVE-2023-6989 through a bug bounty program underscores the value of community engagement in cybersecurity. Researchers, developers, and users must work collaboratively to identify and address vulnerabilities.

Comprehensive Security Strategies: Beyond updating plugins, site owners should employ comprehensive security strategies. This includes using web application firewalls, conducting regular security audits, and implementing security best practices.

Education and Awareness: Raising awareness about common vulnerabilities and promoting security best practices can empower site owners to better protect their sites. Educational initiatives by plugin developers, security firms, and community leaders play a vital role in this effort.

My Final Thoughts

Thanks to resources like FeedSpot, I’m able to keep updated and keep web sites more secure. WordPress site owners can breathe easier with CVE-2023-6989 now addressed, but let this serve as a catalyst for ongoing security education and practices. The digital landscape continues to evolve, and so too must our defenses.

Click here to return to the blog

Click here to return to the main page

2023 Top 10 Vulnerabilities for AWS


In this blog post, we will discuss the top ten vulnerabilities affecting AWS in the year 2023.


Cloud services, just like any other form of IT service or product, need to be managed properly in order to meet particular reliability and availability requirements. This includes making sure the network is available, making preparations for a disaster recovery plan, evaluating the stability of applications and databases, and arranging for redundant infrastructure in various ways.


Sadly, the vast majority of businesses are terrible when it comes to the management of this kind. Small service outages can accumulate in expensive ways.


Here are the top ten AWS vulnerabilities.


  1. Misconfigured permissions and access controls
  2. Unsecured data in S3 buckets
  3. Insufficient monitoring and alerting
  4. Insecure Elasticsearch instances
  5. Inadequate network security
  6. Exposed AWS keys and secrets
  7. Unpatched vulnerabilities in AMIs
  8. Insecure authentication and authorization
  9. Inadequate data encryption
  10. Lack of separation between environments (e.g. dev, staging, prod)


It’s important to regularly review your AWS security settings and practices to ensure that you’re protecting your systems and data against these and other potential vulnerabilities.


Misconfigured permissions and access controls


One example of misconfigured permissions and access controls in AWS is when an S3 bucket is created with public access. This means that anyone on the internet can access the files in the bucket, potentially exposing sensitive data. 


To prevent this, it’s important to properly configure the permissions on your S3 buckets to only allow access to authorized users. This can be done by using AWS Identity and Access Management (IAM) to set up fine-grained access control for your S3 resources.


Unsecured data in S3 buckets


One example of unsecured data in an S3 bucket is when a bucket is created without proper encryption. This means that any data stored in the bucket is not encrypted and could be accessed by anyone who has access to the bucket. 


To prevent this, it’s important to always enable encryption for your S3 buckets, either by using server-side encryption with Amazon S3-managed keys (SSE-S3) or by using client-side encryption with customer-managed keys (SSE-C). This will ensure that your data is always encrypted, both at rest and in transit, and is only accessible to authorized users.


Insufficient monitoring and alerting


One example of insufficient monitoring and alerting in AWS is when an administrator does not set up any alarms or alerts to notify them of potential security issues. For example, if a user’s IAM access keys are compromised, there may be no way for the administrator to be notified and take action to prevent further damage. 


To prevent this, it’s important to set up alarms and alerts that can notify you of potential security issues, such as unauthorized access to your resources or changes to your security settings. AWS provides a variety of tools, such as Amazon CloudWatch and AWS Config, that can help you monitor and alert you on potential security issues.


Insecure Elasticsearch instances


One example of insecure Elasticsearch instances in AWS is when an administrator sets up an Elasticsearch cluster without enabling encryption or authentication. This means that anyone who has access to the cluster can view or modify the data in the cluster without being authorized to do so. 


To prevent this, it’s important to enable encryption and authentication for your Elasticsearch cluster. This can be done by configuring the Elasticsearch nodes to use SSL/TLS for encrypting data in transit and enabling X-Pack security features, such as role-based access control, to secure access to the cluster.


Inadequate network security


One example of inadequate network security in AWS is when an administrator sets up a virtual private cloud (VPC) without properly configuring the security group and network access control list (ACL) rules. This can expose the resources in the VPC to external threats, such as malicious network traffic or unauthorized access. 


To prevent this, it’s important to properly configure the security group and network ACL rules for your VPC to only allow traffic from authorized sources and to block traffic from known malicious IP addresses or networks. AWS provides tools, such as AWS Security Hub and AWS Network Firewall, that can help you monitor and manage your network security.


Exposed AWS keys and secrets


One example of exposed AWS keys and secrets is when an administrator checks their AWS access keys into a public version control system, such as GitHub. This means that anyone who has access to the repository can view the access keys and use them to access the administrator’s AWS account. 


To prevent this, it’s important to never share your AWS access keys publicly and to properly manage and secure your access keys. This can be done by using IAM to create and manage multiple users and access keys within your AWS account, and by using tools such as AWS Secrets Manager to securely store and manage your access keys.


Unpatched vulnerabilities in AMIs


One example of unpatched vulnerabilities in AMIs is when an administrator uses an AMI that is based on an outdated operating system version, such as Amazon Linux 2, that contains known vulnerabilities. This can expose the instances launched from the AMI to security risks, such as malware or other malicious attacks. 


To prevent this, it’s important to regularly update the operating system on your AMIs and to use the latest version of the AMI when launching new instances. AWS provides tools, such as AWS Systems Manager, that can help you patch your AMIs and keep them up to date with the latest security updates.


Insecure authentication and authorization


One example of insecure authentication and authorization in AWS is when an administrator sets up an application that uses an IAM user’s access keys for authentication. This means that the access keys are embedded in the application’s code, and anyone who has access to the code can use the keys to access the user’s AWS resources. 


To prevent this, it’s important to use a more secure method of authentication, such as IAM roles or temporary security credentials. This can be done by using AWS STS to generate temporary security credentials that are tied to an IAM role, and by using these credentials in your application instead of using permanent access keys. This will help to ensure that only authorized users can access your AWS resources.


Inadequate data encryption


One example of inadequate data encryption in AWS is when an administrator sets up an EBS volume without enabling encryption. This means that the data on the volume is not encrypted, and could be accessed by anyone who has access to the volume. 


To prevent this, it’s important to always enable encryption for your EBS volumes. This can be done by using AWS KMS to create a customer-managed encryption key, and then enabling encryption on the EBS volume using the key. This will ensure that the data on the volume is always encrypted, and can only be accessed by authorized users.


Lack of separation between environments


One example of a lack of separation between environments in AWS is when an administrator uses the same IAM users, access keys, and resources for their development, staging, and production environments. This can lead to issues such as code or configuration changes in the development environment being accidentally deployed to the production environment, or sensitive data from the production environment being accessed or modified in the development environment. 


To prevent this, it’s important to properly separate your environments and to use different IAM users, access keys, and resources for each environment. This can be done by using AWS Organizations to create and manage multiple AWS accounts for your different environments, and by using tools such as AWS Service Catalog to manage and control access to your resources.


Most cloud cybersecurity 


Threats stem from poor administration, correct?



many cloud security risks can arise from bad administration, such as misconfigured permissions and access controls, inadequate monitoring and alerting, and a lack of separation between environments. 


It’s important for administrators to understand the security features and best practices provided by their cloud provider, and to regularly review and update their security settings to ensure that their systems and data are protected against potential threats. 


Proper administration and management of cloud environments can help reduce the risk of security incidents and protect against potential vulnerabilities.

Click here to return to the blog

Click here to return to the main page

What’s XSS? How Can You Stop it?


What’s XSS? How can you stop it? As the complexity and usage of web applications increase, so do web application vulnerabilities. Cross-Site Scripting (XSS) vulnerabilities are among the most prevalent forms of online application vulnerabilities. XSS vulnerabilities exploit a flaw in user input sanitization to “write” JavaScript code to the page and execute it on the client side, thereby enabling a variety of attacks.


If a web application accepts unfiltered user input, it is susceptible to XSS. In Javascript, VBScript, Flash, and CSS, XSS is possible.


This vulnerability’s severity is determined by the type of XSS, which is often divided into two categories: persistent/stored and reflected. Depending on the situation, the following attacks may be implemented:


  • Cookie Stealing – The act of stealing a user’s cookie from an authenticated session, allowing an attacker to log in as the user without providing authentication.


  • Keylogging – An attacker can register a keyboard event listener and send all of your keystrokes to their own server.


  • Webcam snapshot – It is possible to capture images from a compromised computer’s webcam using HTML5 capabilities.


  • Phishing – An attacker could either insert fake login forms into the page or redirect you to a clone of a legitimate website in an attempt to obtain your personal information.


  • Port Scanning – You read that correctly. You can use stored XSS to search an internal network and identify other hosts.


  • Other browser-based exploits – XSS offers an infinite number of options.


Who knew that all of this was possible by simply visiting a website? Your browser and anti-virus software have safeguards in place to prevent this from occurring.


Stored cross-site scripting


Stored cross-site scripting is the most dangerous type of XSS. This is when a malicious string originates in the database of a website. This often happens when a website allows user input that is not sanitized (remove the “bad parts” of a user’s input) when inserted into the database.


An attacker creates a payload in a field while registering for a website, which is then saved in the website’s database. If the website does not correctly sanitize that field, when that field is displayed on the page, the payload will be executed for each visitor.


The payload could be as simple as <script>alert(1)</script>


However, this payload won’t just execute in your browser but in any other browsers that display the malicious data inserted into the database.


Reflected Cross-site Scripting


The malicious payload in a reflected cross-site scripting attack is included in the victim’s request to the website. This payload is included in the website’s response to the user. In summary, an attacker must convince a victim to click a URL in order for their malicious payload to be executed.


This may appear safe because it requires the victim to send a request with an attacker’s payload, and a user would not be able to attack themselves. With social engineering, however, an attacker may convince a user to click on a malicious link embedded in an email.


Reflected XSS is the most common XSS attack type.


The attacker sends the victim a URL containing a malicious payload. The attacker tries to trick the victim into clicking the URL. The request could be<script>…</script>


The website sends the user the response with this malicious payload from the request. In response, the victim’s browser will execute the payload. The collected information is then delivered back to the attacker (it might not necessarily be sent from the victim, but to another website where the attacker then gathers this data; this protects the attacker from directly receiving the victim’s data).


What is the DOM


The Document Object Model (DOM) is an interface for programming HTML and XML documents. It represents the page so that programs can modify the structure, style, and content of the document. A web page is a document that can be shown either in the browser window or as the HTML source.



With the object mode, Javascript receives all the abilities necessary to generate dynamic HTML.


A malicious payload is not actually parsed by the victim’s browser during a DOM-based XSS attack until the website’s legitimate JavaScript is run. Then, what does this imply?


With reflective XSS, an attacker’s payload is injected directly into a website, regardless of whether or not another Javascript on the site is loaded.




Phishing attacks are an extremely popular form of XSS attack. Typically, phishing attacks use information that appears legitimate to deceive victims into revealing sensitive information. Common XSS phishing attempts involve injecting bogus login forms that send the login details to the attacker’s server, which can then be exploited to get access to the victim’s account and sensitive information.


Session Hijacking


Cookies are used by modern online apps to maintain a user’s session across many browsing sessions. This allows the user to log in only once and maintain their session even if they revisit the same page at a later time. If a malicious person acquires the cookie data from the victim’s browser, they may be able to log in as the victim’s user without their credentials.


With the ability to execute JavaScript code on the victim’s browser, we may be able to steal their cookies and transfer them to our server in order to hijack their logged-in session using a Session Hijacking (also known as Cookie Stealing) attack.


Protection Methods


Here are three methods for preventing cross-site scripting from occurring in your application.


  1. Escaping: Escape all user input. This means that all data received by your application is secured before being displayed to end users. By escaping user input, the dangerous interpretation of certain characters in the data received by the web page would be prevented. For example, you could disallow the < and > characters from being rendered.
  2. Validating Input: This is the process of verifying that your application displays the proper data and prevents fraudulent data from harming your website, database, and users. Input validation prohibits the submission of specific characters in the first place.
  3. Sanitizing: Finally, sanitizing data is a powerful defense, but it should not be used alone to combat XSS attacks. On websites that permit HTML markup, sanitizing user input is especially beneficial, as it converts invalid user input into an acceptable format. For example, you could sanitize the < character into the HTML entity &#60;


Source and More info @


Click here to return to the blog

Click here to return to the main page

How to Identify and Exploit SQL Injection Vulnerabilities


Welcome to the realm of SQL injection vulnerabilities, a journey marked with technical acuity and not a playground for the uninitiated. Be forewarned, this serves as an enlightening resource, not a charter for unethical activity. Before setting sail into the intricacies of exploits, let’s embark on understanding some fundamental terminologies and structures related to databases.

If you’re not experienced in dealing with databases or exploiting them, there is likely some new terminology to learn, so let’s begin with the fundamentals of how databases are organized and function.


Database: A Primer

Think of a database as an elaborate, electronic treasure chest for your data, governed by a DBMS (Database Management System). These system overseers bifurcate into two camps: Relational and Non-Relational. Our exploration will predominantly focus on the realm of Relational DBMS, delving into the likes of MySQL, Microsoft SQL Server, Access, PostgreSQL, and SQLite.

Picture a DBMS as a grand library with each database as a distinct tome within it. For example, a “shop” database might store discrete sets of data like products, registered users, and orders—each depicted by a unique table within the database.

Tables: The Foundation of Databases

Tables, built with columns (fields) and rows (records), form the fundamental building blocks of databases. Imagine them as a grid: columns (spanning from left to right) classify data types while rows (descending from top to bottom) contain the actual data.

Columns: The Organizing Principle

Fields, each uniquely christened within a table, dictate the kind of data it will hold. The data types range from the commonplace such as integers, text, and dates to the complex data like geographical locations in advanced databases. Setting the data type also acts as a sentry, obstructing irrelevant data input—for example, a “hello world” string in a date column would often raise an error flag. An integer field may have an auto-increment attribute, providing each row a unique number that sequentially increases—resulting in a ‘key field’. This key field, exclusive for each data row, aids precise location during SQL queries.

Rows: The Bearers of Data

In the context of databases, rows or records are individual data entries within a table. Each row stands for a unique instance of data.

Adding new data equals creating a new row; deleting data leads to row removal. A row’s deletion erases all its associated data—unlike emptying fields within the row, the row itself is eliminated, leaving no trace.

These independent rows, through their collective contribution, enable efficient data management and retrieval, fueling the complex operations databases perform.


Relational vs Non-Relational Databases: The Divide

A relational database shelters data in tables that are constantly in conversation. Here, columns define the data parameters while rows store the data itself. These tables usually possess a uniquely identified column (primary key) which other tables reference to establish inter-table relationships, hence the ‘relational’ tag.

In stark contrast, Non-Relational (or NoSQL) databases abandon the rigid structure of tables, columns, and rows. In this arrangement, each data row can contain different information, offering more flexibility than their relational counterparts. Notable examples of this database variant encompass MongoDB, Cassandra, and ElasticSearch.


What is SQL

SQL (Structured Query Language) is a language with numerous features used to query databases; these SQL queries are best referred to as statements.


The most basic of the SQL commands covered in this lesson is used to get select, update, insert, and delete data. Some database servers have their own syntax and subtle differences in operation, despite their similarities.



select * from users;

The first word SELECT instructs the database to retrieve certain data, whereas the * instructs the database to return all columns from the table. For instance, there may be three columns in the table (id, username, and password). “from users” tells the database to fetch the data from the users table. The final semicolon informs the database that the query has reached its end.


select username,password from users;

The next query is identical to the preceding one, but instead of using the * to return all columns in the database table, we are requesting only the username and password fields.


select * from users LIMIT 1;

Similar to the first query, the second returns all columns using the * filter, but the “LIMIT 1” clause restricts the database to returning only one row of data. Changing the query to “LIMIT 1,1” skips the first result, “LIMIT 2,1” skips the first two results, etc. You must remember that the first number tells the database how many rows to return, while the second number specifies how many rows to skip.


select * from users where username=’admin’;

Finally, we will utilize the where clause, which allows us to precisely choose the data we need by returning just the records that match our specific specifications.


This will only return rows where the username matches admin.




The UNION statement combines the results of two or more SELECT statements to retrieve data from a single table or multiple tables; the rules for this query are that the UNION statement must retrieve the same number of columns in each SELECT statement, the columns must have the same data type, and the column order must be identical.




insert into users (username,password) values (‘bob’,’p4ssw8rd123′);

The INSERT statement instructs the database to insert a new data row into a table. “into users” informs the database of the table into which we wish to insert the data, “(username,password)” specifies the fields for which we are supplying data, and “values (‘bob’,’password’);” supplies the data for the requested columns.




update users SET username=’root’,password=’pass123′ where username=’admin’;

The UPDATE statement informs the database that one or more rows of data within a table should be updated. You indicate the table you wish to update by typing “update%tablename% SET” followed by a comma-separated list of the field or fields you desire to update, such as “username=’root’,password=’pass123′.” Similar to the SELECT statement, you can specify precisely which rows to update with the where clause, such as “where username=’admin;”.




delete from users where username=’julie’;

The DELETE statement informs the database that one or more rows of data should be deleted. Except for the absence of the columns you desire to be returned, this query is quite identical to the SELECT. Using the where clause and the LIMIT clause, you may exactly specify the data to be destroyed and the number of rows to be deleted, accordingly.


What is SQL Injection?


A SQL injection attack consists of the insertion or “injection” of a SQL query into an application’s input data from the client. 


A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutting down the DBMS), recover the content of a given file on the DBMS file system, and in some cases issue commands to the operating system. 


SQL injection attacks are a form of injection attack in which SQL commands are injected into the data-plane input to influence the execution of predetermined SQL commands.


In-Band SQL Injection


In-Band SQL Injection is the easiest type to detect and exploit; In-Band simply refers to the same method of communication being used to exploit the vulnerability and also receive the results, such as discovering a SQL Injection vulnerability on a website page and then being able to extract database data from the same page.


Error-Based SQL Injection


Error messages from the database are printed directly to the browser’s screen, making this method of SQL Injection the most effective for acquiring information about the database’s structure. This is frequently used to enumerate an entire database.


Union-Based SQL Injection


This type of injection uses the SQL UNION operator in conjunction with a SELECT statement to return extra results to the page. This is the most prevalent technique for retrieving massive quantities of data via a SQL Injection vulnerability.


Blind SQLi


In contrast to In-Band SQL injection, where the results of our attack are displayed directly on the screen, blind SQLi occurs when we receive little to no feedback to confirm whether our injected queries were successful or not. 


This is because the error messages have been disabled, but the injection still works. It may surprise you that we just require this small amount of feedback to successfully enumerate an entire database.


Authentication Bypass


Bypassing authentication measures, such as login forms, is one of the most basic Blind SQL Injection techniques. In this situation, we are less concerned with retrieving data from the database than with completing the login process.


Typically, login forms that are connected to a database of users are designed so that the web application is not concerned with the contents of the username and password, but rather with whether they form a matching pair in the users table. 


The web application asks the database, “Do you have a user with the username john and the password john123?” and the database responds with either yes or no (true/false). Depending on the database’s response, the web program determines whether or not you can proceed.


Considering the above information, it is unnecessary to list valid username/password combinations. Simply write a database query that returns the value yes/true.

To make this into a query that always returns as true, we can enter the following into the password field:


‘ OR 1=1;–

Why does this work?

The character ‘ will close the brackets in the SQL query
‘OR’ in a SQL statement will return true if either side of it is true. As 1=1 is always true, the whole statement is true. Thus it will tell the server that the email is valid, and log us into the user id.

The — character is used in SQL to comment out data, any restrictions on the login will no longer work as they are interpreted as a comment.


Because 1=1 is a true statement and we’ve used the OR operator, the query will always return true, satisfying the web application’s logic that the database found an acceptable username/password combination and access should be permitted.


<select * from users where username=’%username%’ and password=’%password%’ LIMIT 1;>


Which turns the SQL query into the following: 


<select * from users where username=” and password=” OR 1=1;>


Boolean Based


Boolean-based SQL Injection refers to the response we receive from our injection efforts, which may be true/false, yes/no, on/off, 1/0, or any other response with only two possible possibilities. This result verifies that our SQL injection payload was either successful or unsuccessful. 

At first glance, this brief response may not appear to provide much information. Nevertheless, using only these two responses, it is possible to list the entire database’s structure and contents.


The body of the browser contains the contents of “taken”:true. This API endpoint replicates a common feature present on many signup forms, which prompts the user to choose a different username if the username has already been registered. We can infer that the username admin is already registered since the taken value is set to true. 


In fact, we can verify this by changing the username in the dummy browser’s address bar from admin to admin1, and then hitting enter to observe that the value taken has changed from true to false.




admin1′ UNION SELECT 1,2,3;–


admin1′ UNION SELECT 1,2,3 from users where username=’admin’ and password like ‘admin123%




A time-based blind SQL Injection is quite similar to the preceding Boolean-based variant in that identical requests are issued, but this time there is no visual indication of whether your queries are correct or incorrect. 


Instead, the correctness of a query is determined by how long it takes to complete. This delay is produced by combining the UNION statement with built-in methods such as SLEEP(x). The SLEEP() method will only ever be executed upon a successful UNION SELECT statement.








As damaging as SQL Injection vulnerabilities are, developers, can defend web applications from them by adhering to the below recommendations.


Prepared Statements (With Parameterized Queries)


In a prepared query, the SQL query is written first, followed by any user-supplied parameters. Writing prepared statements guarantees that the SQL code structure does not change and that the database is able to differentiate between the query and the data. Additionally, it makes your code much clearer and easier to read.


Input Validation


Input validation can significantly safeguard the data entered into a SQL query. Using an allow list to restrict input to specific strings or a string replacement mechanism in a programming language to filter the characters you wish to allow or refuse is one way to restrict or filter input.


Escaping User Input


Allowing user input including characters such as(‘ ” $) can cause SQL Queries to fail or, worse, as we’ve seen, leave them vulnerable to injection attacks. The method of escaping user input involves appending a backslash (\) to certain characters, which causes them to be parsed as a regular string and not as a special character.


Source and More info @


Click here to return to the blog

Click here to return to the main page