SQL Injection 101: Understanding

the Basics of SQL Injection Attacks

Understanding SQL Injection 3

What exactly is SQL? 3
What are SQL Queries? 4
How SQL Injection Works 5
Types of SQL Injection 6
#1. In-band SQLi 6
#2. Blind (Inferential ) SQLi 6
#3. Out-of-band SQL Injection 7
Anatomy of A Typical SQL Injection Vulnerability 7
SQL injection examples 8
Examining the database 11
Common Vulnerable Point 13
How common are SQL Injections? 14
How dangerous are SQL Injections? 14
Detection and Prevention 15
Case Study :Heartland Payment Systems Data Breach (2009): 16
FAQ 17
About Codelivly 19

1
Yooo mates, Rocky here! Ever wondered how those hackers manage to slip into databases and
cause chaos? Well, grab a cup of coffee or tea ( the choice is yours man), and let's take a wild
ride into the world of SQL Injection - a technique that's as sneaky as it sounds. Buckle up, it's
gonna be a really crazy ride!

So, what is SQL Injection? It's like the Jedi mind trick of the hacking world. It involves
manipulating a website or application to make it spill the beans from its database. Think of it as a
digital sleight of hand.

Why should you care? Well, SQL is the language that databases understand. If attackers can
inject malicious SQL code, they can control what the database does. Picture a puppet master
pulling the strings behind the scenes.

Now, let's talk real talk. SQL Injection isn't just a theoretical threat. It's caused major data
breaches, financial losses, and headaches for businesses. We'll explore some notorious
examples that will make you raise an eyebrow.

So, buckle up! We're about to unravel the mysteries of SQL Injection in a way that even your
non-tech-savvy friend can nod along with.

2
Understanding SQL Injection

SQL Injection (SQLi) is a notorious form of injection attack that opens the door to executing
malicious SQL statements, giving attackers control over a database server embedded in a
web application. Exploiting SQL Injection vulnerabilities enables perpetrators to circumvent
application security protocols, sidestepping authentication and authorization mechanisms on
a web page or application. The consequences? Unrestricted access to the entire SQL
database, with the ability to retrieve, modify, add, or delete records at will.

This threat isn't picky—it can haunt any website or web application relying on an SQL
database, be it MySQL, Oracle, SQL Server, or others. The stakes are high, as
cybercriminals leverage SQL Injection to infiltrate and abscond with sensitive data. From
customer information and personal data to trade secrets and intellectual property, nothing is
off-limits. Notably, SQL Injection attacks rank among the oldest, most prevalent, and perilous
vulnerabilities afflicting web applications. The Open Web Application Security Project
(OWASP) underscores their severity by placing injections at the top list of their OWASP Top
10 2021 document as the primary menace to web application security.

In simpler terms, SQL Injection is a code-based vulnerability that grants attackers

unauthorized access to sensitive data stored in databases. By cleverly manipulating SQL
queries, they can tamper with, extract, or delete records, wreaking havoc on websites or web
applications reliant on relational databases like MySQL, Oracle, or SQL Server. Recent
years have witnessed numerous security breaches stemming from successful SQL injection
attacks, underscoring the urgent need for robust defenses against this pervasive threat.

What exactly is SQL?

3
Ouuu, hold on a moment! We've ventured pretty far into the realm of SQL Injection without
shedding light on what exactly SQL is. Let's rewind a bit and address this fundamental piece
of the puzzle.

SQL, which stands for Structured Query Language, is the language of databases. It's the
tool that allows us to communicate with and manage relational databases. In simpler terms,
SQL provides a standardized way to interact with databases, making it possible to perform
various operations like storing, retrieving, updating, and deleting data.

Now, back to the main stage. SQL Injection exploits vulnerabilities in the way SQL is
implemented in web applications, allowing mischievous individuals to tamper with the
intended SQL queries and potentially wreak havoc on the associated databases. So, now
that we've got the basics covered, let's continue our journey into the intricacies of SQL
Injection.

What are SQL Queries?

After knowing what SQL is, let's talk SQL queries in plain English. Imagine you have this
magical language that lets you talk to databases. That's SQL (Structured Query Language),
and it's all about asking databases to do things for you.

Now, a SQL query is like giving instructions to a database. You're telling it what data you
want, where to find it, and what to do with it. There are a few basic types of SQL queries:

1. SELECT: This one's like a detective asking for information. You use it to grab data
from a database. SELECT column1, column2 FROM table WHERE condition; For
example, SELECT name, age FROM customers WHERE country = 'USA'; gets the
names and ages of customers from the USA.
2. INSERT: This is like adding a new record to a database. INSERT INTO table
(column1, column2) VALUES (value1, value2); For instance, INSERT INTO
products (name, price) VALUES ('Cool Gadget', 99.99); adds a new product to the
database.

4
 3. UPDATE: Ever make a typo in a document? Well, this is like fixing a mistake in the
database. UPDATE table SET column1 = value1 WHERE condition; An example
could be UPDATE employees SET salary = 50000 WHERE department = 'IT';,
updating the salary for IT department employees.
4. DELETE: This one's like saying goodbye to a record in the database. DELETE
FROM table WHERE condition; So, DELETE FROM orders WHERE status =
'cancelled'; removes canceled orders from the database.

SQL queries are the building blocks that help you interact with databases, whether you're
retrieving info, adding new stuff, fixing errors, or cleaning house. They're the secret language
databases understand, and mastering them opens up a world of data manipulation
possibilities.

How SQL Injection Works

Alright, buckle up! I'm gonna break down how SQL Injection works in a way that won't make
your head spin.

So, picture this: you're on a website, let's call it SuperCoolBlog.com, and they've got this
search bar where you can look up articles. Now, behind the scenes, they're using SQL to
fetch the articles from their database.

Now, let's say you type in something innocent like "latest articles" into the search bar. The
website, in all its glory, converts this into an SQL query like:

SELECT * FROM articles WHERE title = 'latest articles';

Simple, right? It's just fetching articles with the title "latest articles."

Now, here's where it gets interesting. What if, instead of searching for articles, you type
something like:

' OR '1'='1';

This will tweak the original query to become:

SELECT * FROM articles WHERE title = '' OR '1'='1';

Now, '1'='1' is always true. So, this query effectively fetches all articles, not just the ones
matching the title. Congratulations, you've just pulled off a basic SQL Injection!

But wait, there's more! Let's take it up a notch. Imagine you enter something like:

'; DROP TABLE articles; --

Now, the query becomes:

5
 SELECT * FROM articles WHERE title = ''; DROP TABLE articles; --';

Boom! You just injected a command to drop the entire articles table. That's the power of SQL
Injection - manipulating queries to do things they weren't meant to.

Remember, ethical hacking only! Don't go dropping tables where you shouldn't.

Types of SQL Injection

Select an Image

SQL injections are like different flavors of trouble for database, and they usually come in
three main types: In-band SQLi (Classic), Inferential SQLi (Blind), and Out-of-band
SQLi. Let's break them down and peek into their mischief-making ways.

#1. In-band SQLi

This one is like the attacker and the database having a chat on the same channel. It's all
happening in one place.

● Error-based SQL injection: The attacker pulls off actions that make the database spill
its secrets in the form of error messages. It's like getting hints about the database
version and where the server's hidden goodies are stored.
● Union-based SQL injection: Here, the attacker uses the SQL UNION operator to
merge results from different select statements, creating a single response. It's like
playing mix-and-match with the database's responses.

#2. Blind (Inferential ) SQLi

Now, imagine the attacker is blindfolded. They can't see the results, but they're still causing
chaos.

● Boolean-based SQL Injection: The attacker tosses a query to the database and asks
it to return different results based on whether the query is True or False. It's like a
game of 20 questions with the database.

6
 ● Time-based SQL Injection: In this sneaky move, the attacker sends a query that
makes the database wait before responding. The response time becomes the secret
signal for the attacker to figure out if the query hit the bullseye.

#3. Out-of-band SQL Injection

This one's a bit like the oddball, not as popular but still causing a ruckus. It depends on what
features the database server offers.

Now, let's spice things up with a practical example. Imagine you're logging into a website,
and the URL looks like this:

www.example.com/login?username=John&password=12345

An attacker, being all mischievous, tries this:

www.example.com/login?username=John' OR '1'='1'--

If the website isn't properly guarded, this could mess up the login query, allowing
unauthorized access. That's the kind of havoc SQL Injection can unleash, making it crucial to
fortify those web defenses!

Anatomy of A Typical SQL Injection Vulnerability

Alright, let's dissect the anatomy of a typical SQL Injection vulnerability using a practical
example. Imagine you're dealing with a login page where users enter their credentials.

1. The Vulnerable Login Form

Here's a simplified HTML snippet of the login form:

<form action="login.php" method="post"> <label

for="username">Username:</label> <input type="text" name="username"

7
 id="username"> <label for="password">Password:</label> <input
type="password" name="password" id="password"> <input type="submit"
value="Login"> </form>

2. The PHP Code Behind Login

Now, the PHP code (login.php) to handle this form might look something like this:

<?php $username = $_POST['username']; $password = $_POST['password'];

$sql = "SELECT * FROM users WHERE username='$username' AND
password='$password'"; // Execute the query and check for successful
login ?>

3. The SQL Injection Entry Point

Here's where the trouble starts. If the developer hasn't implemented proper input validation
and sanitization, an attacker can manipulate the input fields. Let's say the attacker enters the
following in the username field:

' OR '1'='1' --

The manipulated SQL query becomes:

SELECT * FROM users WHERE username='' OR '1'='1' --' AND password='...'

The double dash -- in SQL indicates a comment, essentially making the rest of the query
irrelevant. The condition '1'='1' is always true, so this query would return a valid user and
potentially grant unauthorized access.

4. Exploiting the Vulnerability

An attacker could enter this manipulated input, click "Login," and voila! They might gain
access without a valid password.

This is a simplistic example, but it highlights the essence of SQL Injection

vulnerabilities—improper handling of user input, allowing attackers to inject malicious SQL
code and manipulate the intended queries. Developers need to implement measures like
parameterized queries or prepared statements to thwart such attacks and ensure the
security of their applications. Always remember, input validation is your friend!

SQL injection examples

8
SQL injection vulnerabilities, attacks, and techniques come in various forms, each posing
unique risks in different situations. Here are some prevalent examples of SQL injection:

1. Retrieving Hidden Data

Manipulating a SQL query to yield additional results, providing unauthorized access to

concealed information. Imagine you have a simple login page where users enter their
credentials. The SQL query might look like this:

SELECT * FROM users WHERE username='input_username' AND

password='input_password';

Now, an attacker might input something like:

' OR '1'='1' --

Resulting in the manipulated query:

SELECT * FROM users WHERE username='' OR '1'='1' --' AND

password='input_password';

This could potentially return all user records, effectively bypassing the login and retrieving
hidden data.

2. Subverting Application Logic

9
Tampering with a query to interfere with the normal flow of an application's logic, potentially
causing unintended consequences. Consider a web store with a query to check if a product
is in stock:

SELECT * FROM products WHERE product_id = 'input_product_id' AND stock >

0;

An attacker might input:

' OR 1=1; --

The altered query becomes:

SELECT * FROM products WHERE product_id = '' OR 1=1; --' AND stock > 0;

This manipulation could subvert the application logic and display products even if they're out
of stock.

3. UNION Attacks

Exploiting the SQL UNION operator to retrieve data from different database tables, granting
access to sensitive information. Suppose you have a search feature querying products:

SELECT product_name, description FROM products WHERE category = 'input_category';

An attacker might input:

' UNION SELECT username, password FROM users; --

This transforms the query into:

SELECT product_name, description FROM products WHERE category = '' UNION

SELECT username, password FROM users; --';

Now, the attacker can retrieve data from the 'users' table along with the product details.

4. Blind SQL Injection

Executing a query where the attacker doesn't directly see the results but infers information
from the application's responses, often leading to unauthorized access or data manipulation.
In a blind SQL injection scenario, the attacker might input:

' OR 1=1; --

10
Even though they can't see the results directly, they can infer from the application's behavior.
For example, if the application responds differently (e.g., a delay) when the condition is true,
the attacker can deduce information without directly seeing the query results.

These examples highlight the versatility and potential danger of SQL injection attacks. It's
crucial for developers to implement secure coding practices to prevent such exploits.

Examining the database

Examining the database is a crucial aspect of understanding and securing systems. Let's
explore how this process works in a practical sense.

1. Browsing Table Contents

In a typical SQL injection scenario, an attacker might attempt to explore the contents of a
database table. For instance, consider a vulnerable login form where the SQL query is
susceptible to injection:

SELECT * FROM users WHERE username='input_username' AND

password='input_password';

An attacker could input something like:

' OR '1'='1' --

Resulting in the manipulated query:

SELECT * FROM users WHERE username='' OR '1'='1' --' AND

password='input_password';

11
Now, if the application is vulnerable, it might return all user records. The attacker effectively
browses the contents of the 'users' table, gaining insights into usernames, passwords, and
potentially other sensitive information.

2. Enumerating Database Structure

Attackers often attempt to gather information about the database structure to plan more
targeted attacks. For example, they might use UNION-based attacks:

' UNION SELECT table_name, column_name FROM information_schema.columns;

--

In this case, the injected query aims to retrieve information about tables and their columns
from the database's information_schema. This enumeration helps attackers understand the
structure of the database and identify valuable targets for further exploitation.

3. Extracting Data Across Tables

In UNION attacks, attackers can combine data from different tables. Suppose a vulnerable
query looks like:

SELECT product_name, description FROM products WHERE category =

'input_category';

An attacker might input:

' UNION SELECT username, password FROM users; --

This transforms the query into:

SELECT product_name, description FROM products WHERE category = '' UNION

SELECT username, password FROM users; --';

Now, the attacker can extract data from both the 'products' and 'users' tables in a single
response, gaining access to sensitive information.

4. Time-Based Blind SQL Injection

In a blind SQL injection scenario, attackers may not directly see query results. Instead, they
manipulate queries to cause delays in responses. For example:

' OR IF(1=1, SLEEP(5), 0) --

If the application takes longer to respond, it indicates that the condition (1=1) is true. This
way, attackers infer information about the database without directly viewing the data.

12
These examples illustrate how attackers can systematically examine and exploit databases
through SQL injection vulnerabilities. It emphasizes the importance of implementing robust
security measures to prevent unauthorized access and protect sensitive information.

Common Vulnerable Point

Identifying common vulnerable points is crucial for securing systems against SQL injection
attacks. Let's explore some typical weak spots that attackers often target:

1. Web Forms and User Input

Web forms are a common entry point for user input. If input validation and sanitation
measures are lacking, attackers can inject malicious SQL code through input fields. Login
forms, search boxes, and registration forms are particularly susceptible.

For example, a vulnerable login form might have a query like:

SELECT * FROM users WHERE username='input_username' AND

password='input_password';

An attacker could manipulate it with:

' OR '1'='1' --

This opens the door for SQL injection.

2. URL Parameters

URL parameters are another playground for attackers. If the application constructs SQL
queries using values from the URL without proper validation, injection becomes a risk.

Consider a URL like:

www.example.com/products?id=123

If the application queries the database using the provided ID without adequate validation, an
attacker might manipulate it:

www.example.com/products?id=123' OR '1'='1' --

Resulting in a potentially vulnerable query.

3. Cookies and Session Variables

If an application stores user-related data in cookies or session variables without proper

validation, these can become targets for injection. Attackers might manipulate these values
to inject malicious SQL code, gaining unauthorized access.

13
4. Hidden Fields

Hidden fields in HTML forms can be manipulated if not properly secured. Attackers may
modify these fields to inject SQL code and exploit vulnerabilities.

5. Stored Procedures

Improperly handled stored procedures can be exploited. If the application relies on stored
procedures and doesn't validate inputs, attackers might inject malicious code when calling
these procedures.

6. Lack of Input Validation

When user inputs are not thoroughly validated and sanitized, attackers can insert malicious
SQL code. Proper input validation ensures that only expected and safe values are accepted.

By understanding and securing these common vulnerable points, developers can

significantly reduce the risk of SQL injection attacks. Implementing best practices such as
parameterized queries, input validation, and regular security audits is essential to fortify
systems against these threats.

How common are SQL Injections?

SQL injections, I tell ya, they're like the sneaky ninjas of the cyber world—quiet, cunning,
and unfortunately, pretty common. It's like that one trick that just won't go away because,
well, it works.

You'll find SQL injections lurking around more often than you'd hope. It's not a rare unicorn;
it's more like that annoying mosquito that keeps buzzing in the background. According to the
cybersecurity scene, they've been around for ages, and they're not going away anytime
soon.

I mean, think about it. Websites, applications, and databases are like treasure chests for
hackers, and SQL injections are the skeleton keys. They go for the weak spots, the
unguarded gates, and if your defenses aren't up to snuff, well, consider yourself a potential
target.

It's not just the small players either. Even big shots, the heavyweights of the tech world, have
fallen victim to SQL injections. So, it's like this digital epidemic that keeps popping up when
you least expect it.

How dangerous are SQL Injections?

Ouuu, SQL injections? they're not just dangerous; they're the daredevils of the cybersecurity
circus. Think of them like the stealthy infiltrators in the cyber underworld—quietly causing
chaos and potentially wreaking havoc on your precious data.

14
The danger level is no joke. SQL injections can open up a Pandora's box of problems. If
successful, attackers can peek into, modify, or straight-up delete your data. I'm talking about
sensitive customer info, personal data, trade secrets—basically, anything the database
holds. It's like giving the keys to your digital kingdom to the wrong folks.

Financial losses? Oh, they're on the menu. A successful SQL injection can lead to
unauthorized access, data theft, and even financial nightmares. Not to mention the hit your
reputation takes. Customers aren't too keen on businesses that can't keep their data safe.

And it's not just about stealing data. SQL injections can mess with the very fabric of your
applications. They can manipulate application logic, mess up authentication, and even bring
down the whole system if things go south.

Here's the kicker: SQL injections aren't a passing fad. They're one of the oldest tricks in the
book, and attackers still love using them. It's like dealing with a persistent and crafty
adversary.

Detection and Prevention

Select an Image

Alright, let's get practical about detecting and preventing SQL injections. We're talking about
putting up a digital fortress to keep those pesky intruders out.

Detection:

1. Web Application Firewalls (WAFs): These are like the guards at the gate. They
scrutinize incoming traffic and look for patterns that match known SQL injection
techniques. If they spot something fishy, they can block it right at the entrance.
Example: You implement a WAF that analyzes requests to your web application. If it
detects SQL injection patterns, it can immediately block the malicious requests.
2. Logging and Monitoring: Keep an eye on the logs. Unusual activities or
unexpected patterns in database queries can be signs of a SQL injection attempt.
Example: Your system logs record all SQL queries executed. If there's an attempt to

15
 inject malicious code, the logs would show unusual query structures or unexpected
parameters.
3. Input Validation and Whitelisting: Be picky about what you accept. Validate and
sanitize user inputs to ensure they match expected formats. Example: If your
application expects an email address, make sure the input follows a valid email
format. Reject anything that looks fishy.

Prevention:

1. Parameterized Queries: This is like building a strong, secure door. Instead of

injecting values directly into SQL queries, use parameters. Example: Instead of:
SELECT * FROM users WHERE username = 'input_username'; Use: SELECT *
FROM users WHERE username = ?;
2. Stored Procedures: Think of stored procedures as the trusted butler who follows a
script. They can help prevent SQL injection by predefining actions. Example: Create
a stored procedure for user login, ensuring that it validates inputs and executes safe
queries.
3. Least Privilege Principle: Don't give more access than needed. Limit the privileges
of database accounts to minimize the impact of a successful SQL injection. Example:
If your application only needs to read data, the associated database account
shouldn't have write or delete privileges.
4. Regular Security Audits: Think of it like spring cleaning for your code. Regularly audit
your application for vulnerabilities and fix any potential issues. Example: Conduct
routine security assessments using tools or professional services to identify and
patch vulnerabilities.

Implementing these measures is like setting up a sophisticated security system. It won't stop
all threats, but it significantly reduces the risk of SQL injections wreaking havoc on your
database.

Case Study :Heartland Payment Systems Data Breach

(2009):
One of the most notorious and impactful SQL injection cases in history is the 2009 Heartland
Payment Systems data breach. Heartland Payment Systems was a major payment
processing company handling credit and debit card transactions for thousands of
businesses.

Background:In 2009, cybercriminals executed a sophisticated SQL injection attack on

Heartland Payment Systems' systems, leading to one of the largest data breaches in the
history of financial transactions.

The Attack:The attackers used a combination of techniques, including SQL injection, to

exploit vulnerabilities in Heartland's payment processing system. They injected malicious
SQL code into the company's systems, enabling them to gain unauthorized access to the
database storing sensitive payment card data.

16
Impact:The consequences were staggering. The attackers managed to compromise the data
of over 130 million credit and debit card transactions. Personal information, including
cardholder names and numbers, was exposed, making it one of the most significant
breaches of financial data.

Detection and Fallout:The breach went undetected for several months, allowing the
attackers to continuously siphon off sensitive information. It was only when financial
institutions noticed an unusual pattern of fraudulent transactions that the breach was
discovered.

The fallout was immense. Heartland Payment Systems faced severe financial and
reputational damage. The company incurred substantial costs related to the breach,
including legal settlements and fines. Additionally, affected individuals experienced the
repercussions of identity theft and financial fraud.

Aftermath and Lessons Learned:The Heartland Payment Systems data breach served as a
wake-up call for the entire industry, highlighting the critical importance of securing payment
processing systems against SQL injection and other cyber threats. It prompted increased
awareness of cybersecurity best practices, the adoption of more robust security measures,
and a heightened focus on compliance with data protection standards.

This case underscores the devastating impact SQL injection attacks can have on
organizations, particularly those handling sensitive financial information. It emphasizes the
need for continuous vigilance, proactive security measures, and a commitment to staying
ahead of evolving cyber threats.

FAQ
Let's cover some frequently asked questions about SQL injection:

1. What is the main goal of SQL injection attacks?

Ans: The primary goal is to manipulate a website or application to execute unintended SQL
queries, allowing attackers to gain unauthorized access to databases, retrieve sensitive
information, modify data, or even delete records.

2. How can I protect my website or application from SQL injection?

Ans:

● Use parameterized queries or prepared statements to ensure that user inputs are
treated as data and not executable code.
● Implement proper input validation and sanitization to filter out malicious input.
● Regularly update and patch your software, frameworks, and libraries to address
known vulnerabilities.

3. Can SQL injection occur in NoSQL databases?

17
Ans: While SQL injection is specific to SQL databases, NoSQL databases are not immune
to injection attacks. They can face similar threats like NoSQL injection, where attackers
manipulate queries in a NoSQL database.

4. Are all SQL injection attacks manual?

Ans: No, not necessarily. Automated tools, such as SQLmap, can be used to identify and
exploit SQL injection vulnerabilities. These tools automate the process of injecting malicious
SQL code and extracting data from databases.

5. Can I rely solely on input validation to prevent SQL injection?

Ans: Input validation is crucial, but it's not a silver bullet. Implementing parameterized
queries or prepared statements is equally important. A combination of input validation,
parameterization, and regular security audits provides a more robust defense against SQL
injection.

6. How do I know if my website is vulnerable to SQL injection?

Ans: Regularly conduct security assessments, including vulnerability scanning and

penetration testing, to identify potential SQL injection vulnerabilities. Monitor logs for unusual
or unexpected queries and patterns.

7. Is it possible to recover from a SQL injection attack?

Ans: Recovering from a SQL injection attack can be challenging, but it's not impossible. It
involves identifying and patching the vulnerability, restoring affected data from backups, and
implementing additional security measures to prevent future attacks.

8. Can a web application firewall (WAF) prevent SQL injection?

Ans: Yes, a WAF can help prevent SQL injection by analyzing incoming traffic and blocking
requests that match known SQL injection patterns. However, it's essential to configure and
update the WAF regularly to stay effective against evolving threats.

These FAQs provide a starting point for beginners to understand SQL injection and its
prevention. It's important for developers and website administrators to delve deeper into
each topic to build a comprehensive understanding of security best practices. That's it for
today matesss. See you on the next Blogs!!

📢 Enjoyed this article? Connect with us On Telegram Channel and Community for more
insights, updates, and discussions on Your Topic.

18
About Codelivly
Codelivly is not just another e-learning platform. It's your
digital classroom, specifically tailored for cybersecurity
aficionados and enthusiasts. We've meticulously curated clear,
concise, and verified modules and blogs that delve deep into the
realms of cybersecurity, next-gen technologies, and beyond.
Whether you're just starting out or seeking advanced knowledge,
our content is crafted to serve every level of learner. With
engaging written modules, blogs, illustrative examples, and
challenging real-world scenarios, we're here to guide you every
step of the way.

Follow Us:

Facebook: facebook.com/codelivly

Twitter: twitter.com

Instagram: instagram.com/codelivly

Telegram: t.me/codelivly

LinkedIN: https://www.linkedin.com/company/codelivly

Visit Us For More : www.codelivly.com

19