Is HTML encoding (percentage encoding) "100%" safe?

[Aeonix]

$allowedForUniversalUsage = htmlEntities($_GET["potentially_super_malicious_code"], ENT_QUOTES);

Does script above help me against XSS and MySQLi injection?

My thoughts would be:

Protection against XSS: Yes
I mean. XSS means that someone would be able to input code, which will be shown publicly and will be executed, the htmlEntities(). It converts actual code into encoded strings, it is as <a href="#">Close</a> according to browser. I can print this, but it won't be executed so it can't really do anything anymore, can it?

Why do I ask, if I found an answer? I still have concerns. Will the line that I served at begin, block malicious content in $_GET["potentially_super_malicious_code"] ? Single quotes, double quotes, penta quotes, triangles, daggers, Doritos everything that could be understood as code, will be parsed into textual-like form? No general way to bypass it?

Protection against MySQLi injection: Yes
Same as with XSS. Doesn't htmlEntities() forbid ' and "'s? Which are super essential? If I bound params, used MySQLi string escapes, allow only alphanumericals and force htmlEntities() parsing, does this block every possible attempt of "bad things happening"?

I know that there are some very high-end website crackers who will find some hyper-super-duper 5TiB long SQL query, which will incinerate the script. But will it keep 99.9% of tryhards/script kiddies away? It is RELATIVELY impossible to break?

Always use a prepared statement for your SQL - don't try sanitizing.
htmlentities() will ensure all tags (and every char with a html entity equivalent) will be encoded.
If you wish to avoid html (alternatively provide a whitelist) - you can use strip_tags()

Few ideas: DW Tutorial: Common Issues with MySQL and PHP

[Aeonix]

Yes, that's 33% of the answer.

But I asked whether htmlEntities(), would provide more security. Over 10 years there will be nutjob that will find way to bypass those prepaired statements mentioned in your tutorial (as we can now evade mysqli_real_escape_string() using non-standard characters, when people thought it was impossible (it is fixable, but soon will be not, then it will, then not anymore etc.)). I was just wondering whether htmlEntities() would help with it. Or it's just another waste of time and processing power. I think it would dodge malicious intents, with mention precautions (that I also mentioned in the post).

The other part is about XSS, is htmlEntities($example, ENT_QUOTES) going to protect me from virtually any type of input?

You can't protect 100% against what somebody may do in the future. That's futile. For example, about 10(?) years ago MD5 was all the rage. Now you'd be insane to use it as a password hash. Things change, and when they do you need a simple way to update. This is where your site and class (or/and functions) structure come in. You don't want certain "once-were-safe" functions littered all over the place, if you can avoid it.

Anyhow 33% of the answer? PS will be exploited? htmlentities() is pretty good, but it will allow simple javascript (without encodable chars/tags) - see this: http://www.paulosyibelo.com/2014/07/bypassing-htmlentities.html

Sorry if I didn't answer the remaining 67%.

Anyhow, considering another thread of yours about "perpetual hosting", it sounds like you're going to build a few sites and just let them run without any maintenance. Tell me you're not, heh heh.

[Aeonix]

You can't protect 100% against what somebody may do in the future. That's futile.

Maaaaaaaaaaaaaaaaaaaaaaaannnnnn...

I know that there are some very high-end website crackers who will find some hyper-super-duper 5TiB long SQL query, which will incinerate the script. But will it keep 99.9% of tryhards/script kiddies away? It is RELATIVELY impossible to break?

Anyhow, considering another thread of yours about "perpetual hosting", it sounds like you're going to build a few sites and just let them run without any maintenance. Tell me you're not, heh heh.

Never! Wow, my reputation preceeds me, if you think I would leave it built once, you must think low of me.

nevermind

[jwenting]

yes, your reputation haunts you. Welcome to the real world.
Just as there is no "lifetime hosting" unless your life is very short, so there is no "100% guaranteed" way to prevent black hats from getting into your systems.
All you can do is make their life harder. And how much effort you invest in that depends on how expensive losing your data to an attacker would be.
If losing your machine's content (and some days of traffic) because you have to format the drives and start from scratch will cost you a million, you can spend a million on intrusion prevention. If it's going to cost you a thousand, you spend a thousand.

Hope u didn.t take badly to my attempt at humour. Wasn.t "dissing" you. I.m with jwenting here when he mentions bangs for bucks. Defence in depth is a mindset but cost may be a consideration. The OWASP site is my go-to place for security issues.

[Aeonix]

Ah, screw it, I give up.

It seems nobody reads to first post. Oh and jwenting https://www.daniweb.com/community-center/threads/499658/recommended-life-time-hosting#post2185508
Big Daniweb used only 2 hostings, I don't see you being offensive douche to whomever stuck along two hostings. Why do you have to be such an a-- against me?

Anyways I'm off, I was mistaken.

[almostbob]

sanitising, is good
$_GET[], mmmmmmmmm not so good
I'm auditing an agency who GET pages, insist that sending information in the uri is secure
exposed the cryptography seed, I could open the system with root access

$_POST[] & SANITISE
for anything heading to the DB, just to not display anything obviously to the user
and the *hyper-super-duper 5TiB long SQL query* won't do much if the uri is not parsed

Small Kudos > Aeonix,
better to be "how much security do I need", than "I don't need security"

Chill A. If I addressed 33% of your question. I hope you found it useful. I tried to answer the htmlentities bit with info about js injection. Also the ref to OWASP. This requires careful study. The defence in depth is what we should aim for but there is also the law of diminishing returns. Budget. Time constraints. Third party security apps etc. Even if you have the budget of a multinational corporation it doesn.t mean that you will be hack-proof.