MySQL - php script - hack

MIT App Inventor Help
21

Hello.
The test project works....
key and SQLKEY are a match

Senior1954

22

OK, good. Does this tell you something about your main php script and blocks ?

23

I tried to send both associative arrays and indexed arrays to the server....but it doesn't appear on the server side in php.... As if there was some problem with POST arrays...

24

I would simplify what you are doing, get that working, then build on it, step by step, testing as you go.

My test (better.php), for example, is a possible starting point...

25

Question: to begin with, it would not be enough to send via POST only the UriEncode query on the server, decode it and run it... Is this weak security? Can a hacker get into the query and change it?

26

Possibly.

The secret key is a first step, but you would need to modify your code considerably to prevent sql injection. Taifun links to sql injection prevention methods, as does the W3Schools php examples (which are a bit easier to understand and implement).

27

OK. Thank you so much for your patience!
Senior1954

28

If a PHP backend receives data from POST and uses it in MySQL queries, the main risks are:

  • SQL Injection: Never concatenate POST values directly into SQL. Use prepared statements and bound parameters.
  • Raw SQL from clients: Never accept a complete SQL query from the browser and execute it. The backend should decide which query runs.
  • Authentication: Make sure the caller is logged in before allowing protected actions.
  • Authorization: Check whether the logged-in user is allowed to access or modify the requested data.
  • User IDs from POST: Do not trust IDs such as user_id or account_id from the request. Derive ownership from the authenticated session where possible.
  • Input validation: Validate type, length, format, allowed values, and required fields before processing data.
  • Mass assignment: Do not automatically save every POST field. Explicitly allow only fields users are permitted to change.
  • CSRF: Protect browser-based authenticated requests with CSRF tokens and appropriate cookie settings.
  • Rate limiting: Limit repeated requests to reduce brute-force attempts, abuse, and denial-of-service risk.
  • Database permissions: The web application should use a restricted MySQL user, never the root database account.
  • Passwords and secrets: Keep database credentials and API keys outside publicly accessible files and source repositories.
  • HTTPS: Always use HTTPS so login credentials, sessions, and submitted data are encrypted in transit.
  • Error handling: Never expose SQL errors, stack traces, file paths, or credentials to users.
  • Session security: Use secure, HTTP-only, SameSite cookies and regenerate session IDs after login.
  • File uploads: Restrict file types, sizes, filenames, and storage locations. Never trust the uploaded extension alone.
  • XSS: Escape user-generated content when displaying it in HTML.
  • Command execution: Never pass POST data directly into shell commands or system functions.
  • Logging: Record suspicious authentication failures, denied actions, and unusual request patterns.
  • Backups: Maintain tested database backups so attacks or accidental corruption can be recovered from.
  • Updates: Keep PHP, MySQL, frameworks, libraries, and the operating system patched.
  • Least privilege: Give every user, service, and database account only the permissions it actually needs.

The core principle is: treat everything coming from the browser as untrusted, validate it, authorize it, and keep database logic controlled by the server.