Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.
Get it on
Google Play
4.9/5 Rating on Store
Ethical hacking · Question Set
Exploitation Basics interview questions for placements and exams.
Questions
15
Included in this set
Subject
Ethical hacking
Explore more sets
Difficulty
Mixed
Level of this set
Go through each question and its explanation. Use this set as a focused practice pack for Ethical hacking.
Dot dot slashes try to walk out of the intended folder. Servers should normalize paths, drop dot segments, and restrict to an allowlisted base directory. Never concatenate raw user paths to filesystem calls.
safePath = join(BASE, normalize(userPath)); assert(safePath.startsWith(BASE))
For complete preparation, combine this set with full subject-wise practice for Ethical hacking. You can also explore other subjects and sets from the links below.
Think of it like dominos. One low-impact issue opens the door to the next issue, and so on. For example, info leak gives a secret, which lets you bypass auth, which then exposes an admin panel. Chaining small findings is how real attacks are built, so always ask, what does this enable next?
Example chain: info leak → weak token → admin panel → file upload → R C E
Never fire a PoC without clear permission, timing, and contingency steps. Get the owner ready, understand the impact, and know how to undo changes. Safe execution keeps trust and prevents outages.
Plan: scope_ok=true; window=approved; owner_on_call; revert_steps=ready
If adding characters like semicolon or pipe alters server behavior, you may be hitting the shell. Ethical tests use safe, low-impact checks like time delay or harmless commands. Stop at proof and avoid destructive actions.
name=ana; echo test // look for the word test in the response or timing change
If a server deserializes data from the user without strict checks, attacker-controlled objects can trigger dangerous code paths. Safer designs use signed tokens, strict formats like JSON with schema checks, or a deny-by-default type binder.
Safer plan: JSON + schema validate → map to DTO → business object
Strong upload defense is layered. Validate type and content, never execute uploads, and isolate storage from direct web access. Scan files server-side and serve via a download endpoint, not straight from disk.
accept: ['.jpg','.png'] + magic bytes check → store /data/blobs → GET /download/:id
R C E gets you a foothold. L P E turns a low-privilege foothold into admin. In real work, attackers often do both: first land code, then escalate to broaden impact.
Flow: foothold (R C E) → enumerate → privilege escalation (L P E)
You treat the app as a black box. You mutate inputs, feed edge cases, and observe responses and timing. It is a fast way to spot weak parsing and boundary bugs before deeper analysis.
ffuf -w params.txt -u https://app/item?FUZZ=1 -mc 200,500 -t 5
First, confirm scope and the approved window. Use a dedicated test account or non-production path if possible. Start with a harmless probe that changes only the response, like echoing a token or adding a very small time delay. Do not read sensitive files, do not spawn shells, and do not change system state. Capture the exact request and response as evidence. Stop after minimal proof. Share impact, fix, and reproduction notes with the owner. Your goal is to prove risk, not to maximize it.
color=blue; echo SAFE_TOKEN_123 // look for SAFE_TOKEN_123 in response or logs
Verify written permission, scope, and the exact target list. Read the PoC code to understand actions and defaults. Test it in a lab first. Set rate limits and timeouts. Get a rollback plan and backups ready. Have the system owner and monitoring team on standby. Log everything you do and stop at first sign of instability. Never run unknown binaries. Prefer reviewed source, and remove any destructive steps. Proof should be minimal and reversible.
Checklist: scope ✔ lab test ✔ owner on-call ✔ backup ✔ revert steps ✔ logging ✔
Start by reviewing server responses and storage paths. Try only benign file types first. Check if uploads are served back from a public path. If you suspect execution, ask for explicit approval before attempting any dynamic file. Use a harmless marker file to see if the server interprets it or just stores it. Never attempt dangerous payloads without written consent, and never overwrite existing files. If risk is confirmed, recommend strong controls: strict allowlist, magic-byte checks, storage outside web root, and a download proxy.
1) Upload benign.jpg → fetch via random URL 2) Verify no execution, only download behavior 3) Report evidence and propose controls
Use out-of-band or timing-based signals that do not touch sensitive data. For timing, use a tiny, bounded delay and run it once. For out-of-band, use a controlled collaborator endpoint to receive a single DNS ping. Keep the probe minimal, log the exact time, and stop after you observe the signal. Share the smallest proof that demonstrates control, then focus on fixes. Avoid extra trials in production.
Timing probe: add a two-second delay once and measure response time O O B probe: resolve unique token.your-listener.example once
Identity is a force multiplier. If a bug lets you act as another user or role, it can unlock panels, endpoints, and data that amplify impact. Start where access level jumps, then chain to sensitive actions.
Priority: auth bypass → admin → sensitive actions → data impact
Local File Inclusion stays within the host, like reading logs or config files. Remote File Inclusion lets the server fetch and sometimes execute remote content. Tight include logic and allowlists prevent both.
LFI probe: ?page=../../../../var/log/app.log
Enumerate first. Check who you are, groups, sudo policy, kernel and OS, running services, cron jobs, SUID files, writable paths, and environment variables. Look for weak file permissions and leaked secrets in configs or history. Avoid noisy actions. If a path looks risky, pause and seek approval before trying it. Document commands and outputs. If you gain higher rights, place a harmless marker file as proof and help the owner validate fixes after the test.
id; uname -a; sudo -l; ls -la /etc/cron.*; find / -perm -4000 -type f 2>/dev/null