How Criminals Target Databases: Common Attack Methods and How to Defend Against Them

UPI Study › Courses › Ethics in Technology › Free lessons › Lesson 9.1 Free with a free account

How Criminals Target Databases: Common Attack Methods and How to Defend Against Them

Ethics in Technology · Chapter 9: Data Breaches, Digital Infections, and the Malware EcosystemSection 9.1 · lesson 42 of 11615 min · free with a free account

← Intrusion Detection SystemsNext lesson: Laws That Require Organizations to Tell You When Your Personal Data Has Been Compromised →

Earn 3 college credits for Ethics in TechnologyRecommended for credit by NCCRS · Computer Science 195 · self-paced · one payment, lifetime access
Enroll in Ethics in Technology · $250 →Download the syllabus (PDF)

In this lesson

Common attack routes and the controls that reduce their reach.

  • Identify application, account, authentication, and exposure routes
  • Separate query structure from supplied values
  • Explain document-query and validation safeguards
  • Apply least privilege, identity protection, copy control, and monitored defense

Free study notes

Get this lesson's notes by email

The key points and 4 practice questions with answers, in your inbox. One email, free.

One email. Unsubscribe in one click.

Transcript

Everything said in the video, section by section (1,780 words). Read along, or search it.

Chapter 9

How Criminals Target Databases

Databases organize valuable records for fast retrieval, which also makes their protection important. The source groups attack routes through applications, account privileges, weak authentication, and exposed services or copies. These routes can overlap, and a copied dataset may bypass the application entirely. We explain injection as untrusted information being interpreted as part of an instruction. Correct parameter binding keeps ordinary supplied values separate from executable query structure. Document queries can face the same problem when untrusted objects control operators instead of plain values. Server validation checks expected meaning and complements safe query construction. Least privilege limits the authority available through application and human identities. Strong authentication and protected credential lifecycles reduce easier entry paths. Inventory, suitable boundaries, encryption, and retention controls follow data into backups, exports, and tests. Finally, we connect complementary layers with monitored evidence and practical response to the activity that remains.

Four Source Routes

Different Paths Can Reach the Same Structured Records

The first route reaches records through an application that builds or enforces its requests unsafely. Injection can change an instruction when untrusted content becomes executable structure. The second route uses a legitimate account, through excessive grants, misuse, or another person borrowing access. The third involves weak authentication, including applicable defaults, reused secrets, or inadequate failure controls. The fourth reaches an exposed instance or copy, sometimes outside the application altogether. Names, payment records, health information, messages, and credentials may all deserve protection. Searchable structure helps legitimate work and can also make unauthorized retrieval efficient. Protecting the live database does not automatically protect a forgotten export elsewhere. Known preventable weaknesses deserve attention alongside novel threats and supplier or implementation failures. These categories are teaching routes, rather than an exhaustive classification with one exclusive label per incident. Assess the actual data, reachable authority, exposure, and consequences before choosing the protections that matter.

Injection Concept

Untrusted Data Must Not Become Part of the Instruction

Injection occurs when untrusted information is interpreted as part of an instruction instead of as data. Consider a site looking up an account that matches a supplied username. The developer intends a particular operation and comparison, with the name occupying a value position. An unsafe implementation joins fixed instruction text directly to the visitor's untrusted input. The resulting executable text combines the intended structure with content that came from outside. Input treated as syntax can then change conditions or operations within the permissions available. The database executes the received instruction, rather than inferring the application's intended trust boundary. An ordinary submitted name may work correctly, which can hide the underlying construction flaw. The defensive issue is separation of instructions and values, not identifying one special dangerous word. Related interpreted formats can suffer a similar boundary mistake, even with different syntax. We can understand and prevent that mistake without providing an attack payload or operational intrusion instructions.

Parameterized Queries

Keep the Trusted Query Structure and the Values Separate

The unsafe conceptual pattern inserts the supplied value into an executable text string. The safe illustrative pattern uses a trusted query with a placeholder and sends the value separately. Here, the intended query compares the stored name with a separately bound name value. The driver's supported binding mechanism keeps that name in the value position. Unusual punctuation in the submitted name remains data for comparison, rather than changing the query's structure. The example joins two developer-controlled literal pieces only to display the trusted query conveniently. That differs from joining untrusted input into the executable instruction. Actual placeholder syntax and parameter calls vary by database and driver. Use the correct supported interface, rather than substituting text into the placeholder yourself. This protection does not establish that the caller may read a record that matches. Authorization and the other database controls still need to protect the intended business operation.

Boundaries of the Remedy

Correct Binding Is Essential, and Each Query Path Still Needs Review

Correct parameter binding protects ordinary supplied values from becoming executable query structure. Some structural choices, including identifiers or sort directions, cannot use an ordinary value placeholder. Keep those choices controlled through suitable mapping, approved structure, or query redesign. A variable called parameter is not automatically a safely bound value. Driver behavior and the actual execution call determine whether the separation exists. Stored procedures are not automatically safe when they construct unsafe dynamic queries internally. Review helper code, raw-query paths, and later reuse of previously stored untrusted information. The source explains protection through a plan fixed before the supplied values arrive. The reliable security distinction is separate structure and values; optimizer planning behavior is not universally identical. Filters can miss encodings or forgotten paths, while a correct binding mechanism addresses the value boundary directly. Implementation mistakes and unprotected structural positions still need review, alongside validation, authorization, least privilege, and monitoring.

Document Database Queries

Structured Objects Can Also Confuse Values with Operators

Document databases can express comparisons through structured query objects, without requiring a SQL text string. That different format does not remove the possibility of instruction and data confusion. If a whole request object becomes the database query, its structure may control unintended operations. A nested operator where the application expected a plain string can also change the comparison's meaning. Validate the fields and types that the intended operation accepts. Then construct the intended query using suitable driver features and the validated values. The illustrative Python-style pattern rejects a supplied name that is not a string. It then places the plain string inside the application's chosen name comparison. Driver objects alone are insufficient when untrusted nested structures can still become query operators. Document databases are not all free of textual query languages, so avoid that universal claim. The broader remedy is retained control of interpreted structure, regardless of the database's label or query notation.

Input Validation

Enforce Meaning on the Server, Alongside Safe Query Construction

Validation checks what the application expects, rather than deciding whether the input looks like an attack. A postal field needs rules appropriate to the supported country and format. A quantity needs its expected type, permitted range, and relevant business constraints. A generated identifier needs the system's format, while format alone does not establish access rights. Enforce these rules on the server, even when the browser also provides immediate feedback. Requests can bypass browser checks, so those checks are not a dependable security boundary. Define acceptable types, lengths, ranges, formats, and meanings for each field. Avoid silently stripping characters into a submission with a different meaning. Intentional consistent normalization may be useful when it preserves the field's defined semantics. It does not replace parameter binding, output protection, or authorization. Validation and query binding perform different jobs, and legitimate names can contain punctuation without becoming malicious.

Privilege Abuse

An Account Can Work as Configured and Still Be Used Wrongly

Privilege abuse can occur when an account works exactly as configured. Excessive privilege grants more authority than the account's actual job requires. Reduce grants, review them, and remove obsolete access when responsibilities change. Misuse involves held permissions used for an unjustified purpose, rather than necessarily exceeding technical authority. Looking up a neighbor, celebrity, or former partner can illustrate that distinction. Use suitable purpose-aware audit, staff notice, and investigation of access unconnected with legitimate work. Borrowed access occurs when another party uses a stolen or otherwise acquired credential. Strong authentication, credential lifecycle controls, unusual-access review, and limited retrieval authority help reduce that risk. These patterns can overlap, without needing an invented share of all breaches. An anomalous lookup warrants assessment, rather than an automatic finding that an employee committed wrongdoing. Collect useful audit evidence while avoiding unnecessary sensitive contents and preserving the privacy of the people monitored.

Application Account

Give the Running Application the Authority Its Work Actually Needs

An application identity should have the authority its running business functions actually need. Map required tables, rows, columns, and actions, using the database's suitable permission features. A routine service commonly does not need general account creation or schema administration. Use independently controlled paths for approved migration and administration work. Avoid granting convenience power over protected audit evidence and recovery copies. If an attacker controls the application identity, its effective permissions shape the possible damage. An administrative connection can expose much broader actions and records than the application's normal task requires. A restricted identity limits reach, while permitted business access can still be abused. Narrow permissions, test legitimate workflows, separate environments, and review changes. The effort depends on existing functions and architecture, rather than always being an afternoon's work. Least privilege reduces authority; it does not prove a compromised account cannot cause serious harm with its remaining access.

Authentication Weaknesses

Reduce Easy Entry, Preserve Attribution, and Protect Secrets

Remove, disable, or replace applicable default credentials before exposing a service, and verify deployment. Individual human identities support removal and attribution without relying on one shared team password. Controlled privileged brokering may also preserve links to individual sessions. Unique suitable credentials and stronger authentication reduce reuse and stolen-password risks. Compromised sessions, recovery paths, and excessive permissions can still matter despite a second factor. Machine identities need appropriate noninteractive authentication, rather than assuming human multifactor steps fit every process. Throttle and monitor repeated failures, with careful lockout and error-feedback design. Protect secrets outside source and exposed exports, using suitable secret-management or workload-identity arrangements. Detect leaks and revoke or rotate appropriately; merely moving an already leaked secret does not invalidate it. Provision needed access, review it, and remove or change it on departure, role change, or suspected compromise. An identity in a log supports investigation, but does not alone prove which human performed the activity.

Instances and Copies

Protection Must Follow Data Beyond the Production Application

Protect the data wherever it exists, including backups, snapshots, exports, and testing environments. Restrict live database and management paths to their required boundaries, with appropriate authentication. Public storage or weak backup permissions may expose a copy without the application's access checks. Restrict copy retrieval and changes, and protect encryption keys as well as encrypted files. Inventory temporary copies with owners, purposes, retention, and relevant removal obligations. Prefer suitable artificial test data; protect any justified use of real production information. Detailed public errors can reveal internal structure, so keep necessary diagnostics in protected evidence. Authorized checks of the organization's own external footprint can identify unnecessary reachability. Administrative decisions and technical enforcement work together; these remedies are not exclusively paperwork. Discovery timing varies, and accessing every exposed resource does not require the same level of skill. Inventory and access review are valuable without claiming a universal largest-breach category or a fixed hours-to-discovery deadline.

Layered Defense and Review

Design Complementary Controls, Then Monitor the Paths That Remain

The source's six layers connect safe queries, input checks, least access, authentication, exposure control, and monitoring. Write queries so ordinary supplied values remain separate from executable structure. Check appropriate field meaning and types on the server. Grant each application identity only the records and actions its work requires. Protect human and machine identities throughout their credential lifecycles. Restrict unnecessary reach to live services, copies, and management access. Record useful evidence, investigate abnormal activity, and assign practical response ownership. Complementary controls should cover different routes and avoid one failure removing several protections. An exposed backup may bypass application controls; attacks do not always pass through every layer in sequence. Large retrieval volume needs context for legitimate bulk work, with protected logs supporting investigation and response. Review binding, character stripping, document-query structure, application privilege, and copy inventory to apply the lesson's defensive reasoning.

About Ethics in Technology at UPI Study

Ethics in Technology (Computer Science 195) is a self-paced online course of 116 video lessons in 15 chapters, from cybersecurity basics, privacy and surveillance to big data, hacking, malware, network defense, intellectual property, cybercrime, encryption, emerging technology and digital citizenship. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses

Compare: Cybersecurity vs Ethics in Technology · Which ethics course?

Why take it here

Why students take Ethics in Technology with UPI Study

The right and wrong of the digital worldEthics in Technology looks at the choices technology forces on people and organizations: security and privacy, surveillance and the law, big data, hacking and cyber warfare, malware and breaches, intellectual property, cybercrime, encryption, artificial intelligence and responsible digital citizenship. It suits computer science, information technology and business degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Ethics in Technology carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About How Criminals Target Databases: Common Attack Methods and How to Defend Against Them

What is SQL injection?
SQL injection is an attack where untrusted input is treated as part of a database command instead of as data. It happens when code joins user input directly into query text, for example inserting a typed username into a lookup statement. Input written as query syntax can then change conditions or operations within the application's permissions. The root cause is mixing instructions and values, not any one dangerous word, so blocking keywords is unreliable.
How do parameterized queries prevent SQL injection?
Parameterized queries use a fixed query with placeholders and send user values separately through the database driver, so a value can never change the query's structure. A name containing unusual punctuation is simply compared as data. Placeholders cannot hold table names or sort directions, so those must come from an approved list. Stored procedures that build dynamic SQL internally can still be vulnerable, and authorization checks are still needed.
Can NoSQL databases have injection attacks?
Yes, document databases such as MongoDB can suffer injection even without SQL text. If an application passes a whole request object into a query, or accepts a nested operator object where it expected a plain string, the attacker's input can change what the query compares. The fix is to validate each field's expected type, such as rejecting a username that is not a string, and then build the query from those validated values.
Why should an application's database account have limited privileges?
An application's database account should have only the access its functions need because, if attackers take over the application, that account's permissions set the limit of the damage. A routine web service rarely needs to create accounts, change schemas or touch audit logs and backups. Administration and migrations should use separate, controlled identities. Least privilege reduces harm but does not make a compromised account harmless, so monitoring is still needed.

About the Ethics in Technology course

How many college credits is Ethics in Technology?
Ethics in Technology (Computer Science 195) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Ethics in Technology cost and what is included?
$250, paid once, with lifetime access: all 116 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. It is sold on its own and is not part of UPI Study PRO.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Ethics in Technology take?
It is self-paced with no deadlines. The 116 lessons total about 28 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Ethics in Technology.

116 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in Ethics in Technology →Download the syllabus
Ethics in Technology
3 credits · NCCRSEnroll →