TRWTF is PHP



  • HLstatsX:CE. They programmed it using PHP/MySQL so it would work on cheap hosting. But it requires a perl daemon and a Source engine game server, which you can't run on generic shared hosting.

    There are many, many things about this code that make me want to vomit. Yes, they are using variables from $_GET in an sql query without sanitizing them.

    Or are they?

    $map = valid_request($_GET['map'], 0);
    That's a bit strange looking for a sanitization call. Let's look further.

    Hmm, here it is!

    <?php
    /**
    * valid_request()
    * 
    * @param string $str
    * @param boolean $numeric
    * @return mixed request
    */
    function valid_request($str, $numeric = false)
    {
    	$search_pattern = array("/[^A-Za-z0-9\[\]*.,=()!\"$%&^`�':;߲�#+~_\-|<>\/\\\\@{}������ ]/");
    	$replace_pattern = array('');
    	$str = preg_replace($search_pattern, $replace_pattern, $str);
    	if ( $numeric == false )
    	{
    		if ( get_magic_quotes_gpc() )
    			return $str = htmlspecialchars(stripslashes($str), ENT_QUOTES);
    		else
    			return $str = htmlspecialchars($str, ENT_QUOTES);
    	}
    	else
    	{
    		if ( is_numeric($str) )
    			return intval($str);
    		else
    			return -1;
    	}
    }
    

    Where to begin? "return $str = "? The fact that they're using htmlspecialchars as a replacement for database sanitization? The preg_replace with arrays instead of strings? The random garbage bytes they put into the regular expression? "if ( $numeric == false )"? The fact that they called a function with 0 as the value of an optional boolean that defaults to false?


  • Discourse touched me in a no-no place

    @Ben L. said:

    The random garbage bytes they put into the regular expression?
    It was probably written in another encoding than the one you're using, and whatever information was there is now long gone, converted to replacement characters. Anyone up for a game of “guess the encoding”? It's a bit like charades, but much less interesting.



  • @Ben L. said:

    HLstatsX:CE. They programmed it using PHP/MySQL so it would work on cheap hosting. But it requires a perl daemon and a Source engine game server, which you can't run on generic shared hosting.

    So if they wrote it in C# it would run really good on those VPS' that run Linux, which could have Perl installed and a SourceDS instance running?




  • @gu3st said:

    @Ben L. said:
    HLstatsX:CE. They programmed it using PHP/MySQL so it would work on cheap hosting. But it requires a perl daemon and a Source engine game server, which you can't run on generic shared hosting.

    So if they wrote it in C# it would run really good on those VPS' that run Linux, which could have Perl installed and a SourceDS instance running?



    If they wrote it in SourcePawn, which part of it is, they could have skipped the whole "parse the logs" step and dropped the data straight into the database. They also wouldn't need to tie up a UDP port or require perl at all.



  • @Ben L. said:

    If they wrote it in SourcePawn, which part of it is, they could have skipped the whole "parse the logs" step and dropped the data straight into the database. They also wouldn't need to tie up a UDP port or require perl at all.

    Seriously? Last I checked SourcePawn didn't even have dynamic memory allocation, let alone database access routines.

    @Ben L. said:

    Where to begin? [...] The fact that they're using htmlspecialchars as a replacement for database sanitization?

    You are TRWTF.



  • @Ben L. said:

    The fact that they're using htmlspecialchars as a replacement for database sanitization?

    In the whole of my PHP career, I haven't used anything else for sanitization (when not using frameworks), and to this day I have found no way nor anyone who would find a way to SQL inject anything through that.

    However, if you know of a way, I'd be happy to learn as it still seems unbelievable to me that this simple function would be so effective.



  • Is anyone really surprised that something written in PHP is a steaming pile?



  • @Salamander said:

    @Ben L. said:
    If they wrote it in SourcePawn, which part of it is, they could have skipped the whole "parse the logs" step and dropped the data straight into the database. They also wouldn't need to tie up a UDP port or require perl at all.

    Seriously? Last I checked SourcePawn didn't even have dynamic memory allocation, let alone database access routines.

    It has [url=http://docs.sourcemod.net/api/index.php?fastload=file&id=22&]database access routines[/url] (under "dbi"; I tried to link it directly but the function list "helpfully" stays collapsed).  In fact, it has [b]always[/b] had database access routines.... at least since its first public release.

    Unfortunately, it only supports SQLite and MySQL (plus clones).

     



  • @Ben L. said:

    @gu3st said:
    @Ben L. said:
    HLstatsX:CE. They programmed it using PHP/MySQL so it would work on cheap hosting. But it requires a perl daemon and a Source engine game server, which you can't run on generic shared hosting.

    So if they wrote it in C# it would run really good on those VPS' that run Linux, which could have Perl installed and a SourceDS instance running?



    If they wrote it in SourcePawn, which part of it is, they could have skipped the whole "parse the logs" step and dropped the data straight into the database. They also wouldn't need to tie up a UDP port or require perl at all.
     

    Its been a while since I've done Source logging stuff or examined the values of the player_death event  As I recall, the logs contain information that's not available to the player_death event.



  • @powerlord said:

    @Ben L. said:

    @gu3st said:
    @Ben L. said:
    HLstatsX:CE. They programmed it using PHP/MySQL so it would work on cheap hosting. But it requires a perl daemon and a Source engine game server, which you can't run on generic shared hosting.

    So if they wrote it in C# it would run really good on those VPS' that run Linux, which could have Perl installed and a SourceDS instance running?



    If they wrote it in SourcePawn, which part of it is, they could have skipped the whole "parse the logs" step and dropped the data straight into the database. They also wouldn't need to tie up a UDP port or require perl at all.
     

    Its been a while since I've done Source logging stuff or examined the values of the player_death event  As I recall, the logs contain information that's not available to the player_death event.


    player_death event has a bunch of information. Compare that to this line from my log:

    L 02/05/2014 - 11:37:51: "Minh<27><BOT><TERRORIST>" [2419 1112 160] killed "Reed<32><BOT><CT>" [2196 1121 212] with "sg556" (headshot)

    The team, position, and SteamID of a player can be obtained easily in sourcemod using their user id.



  • @mikeTheLiar said:

    Is anyone really surprised that something written in PHP is a steaming pile?



    Of course, if it was written in .NET it would be GOLD !
    I mean, the code would be re-written on the fly by the magic .NET compiler, optimized and made to run on any platform.


    The proof is Community Server. It's such a great product BECAUSE it's .NET. If it was written in PHP, it would be a steaming pile of shit, whoever wrote it would not make a difference.

    That's why all the top million busiest sites are built with .NET because they need performance. PHP would not scale since it is JUST SHIT !

    Proof : on those sites, IIS represent a huge 12.56% of the market !



  • @Ben L. said:

    @powerlord said:

    @Ben L. said:

    @gu3st said:
    @Ben L. said:
    HLstatsX:CE. They programmed it using PHP/MySQL so it would work on cheap hosting. But it requires a perl daemon and a Source engine game server, which you can't run on generic shared hosting.

    So if they wrote it in C# it would run really good on those VPS' that run Linux, which could have Perl installed and a SourceDS instance running?



    If they wrote it in SourcePawn, which part of it is, they could have skipped the whole "parse the logs" step and dropped the data straight into the database. They also wouldn't need to tie up a UDP port or require perl at all.
     

    Its been a while since I've done Source logging stuff or examined the values of the player_death event  As I recall, the logs contain information that's not available to the player_death event.


    player_death event has a bunch of information. Compare that to this line from my log:

    L 02/05/2014 - 11:37:51: "Minh<27><BOT><TERRORIST>" [2419 1112 160] killed "Reed<32><BOT><CT>" [2196 1121 212] with "sg556" (headshot)

    The team, position, and SteamID of a player can be obtained easily in sourcemod using their user id.

     

    I'm at work, so can't test this, but what value does a player's m_vecOrigin netprop (aka the player's position) have when they're dead?  Remember, events in Source are notifications of something that already happened, so they're already dead before your code sees the event.  I always assumed said position would be 0.0, 0.0, 0.0 (aka the World Origin), although it may depend on the game's spectate settings.

    That's ignoring the issue how player_death varies from game to game, as that can be coded around using GetEngineVersion blocks.

     



  • @powerlord said:

    @Ben L. said:

    @powerlord said:

    @Ben L. said:

    @gu3st said:
    @Ben L. said:
    HLstatsX:CE. They programmed it using PHP/MySQL so it would work on cheap hosting. But it requires a perl daemon and a Source engine game server, which you can't run on generic shared hosting.

    So if they wrote it in C# it would run really good on those VPS' that run Linux, which could have Perl installed and a SourceDS instance running?



    If they wrote it in SourcePawn, which part of it is, they could have skipped the whole "parse the logs" step and dropped the data straight into the database. They also wouldn't need to tie up a UDP port or require perl at all.
     

    Its been a while since I've done Source logging stuff or examined the values of the player_death event  As I recall, the logs contain information that's not available to the player_death event.


    player_death event has a bunch of information. Compare that to this line from my log:

    L 02/05/2014 - 11:37:51: "Minh<27><BOT><TERRORIST>" [2419 1112 160] killed "Reed<32><BOT><CT>" [2196 1121 212] with "sg556" (headshot)

    The team, position, and SteamID of a player can be obtained easily in sourcemod using their user id.

     

    I'm at work, so can't test this, but what value does a player's m_vecOrigin netprop (aka the player's position) have when they're dead?  Remember, events in Source are notifications of something that already happened, so they're already dead before your code sees the event.  I always assumed said position would be 0.0, 0.0, 0.0 (aka the World Origin), although it may depend on the game's spectate settings.

    That's ignoring the issue how player_death varies from game to game, as that can be coded around using GetEngineVersion blocks.

     

    Your corpse is technically still you, even after you die. The only Source game I know of where your corpse can get destroyed is TF2, and I think it counts your torso as "the player's body" when you explode. There's also Alien Swarm, where the players don't physically enter the world (for some reason, marines are NPCs controlled by players. Yep, confusing).

    In any case, I think the event happens before you become a corpse but after you hit 0 health, so there should be no issues with position.



  •  If you’re worried about sanitizing your database inputs, you’ve already lost.



  • @Sir Twist said:

     If you’re worried about sanitizing your database inputs, you’ve already lost.


    Parameterized queries are a form of sanitization, so I guess those are right out.



  • @SEMI-HYBRID code said:

    @Ben L. said:
    The fact that they're using htmlspecialchars as a replacement for database sanitization?
    In the whole of my PHP career, I haven't used anything else for sanitization (when not using frameworks), and to this day I have found no way nor anyone who would find a way to SQL inject anything through that.
    However, if you know of a way, I'd be happy to learn as it still seems unbelievable to me that this simple function would be so effective.

    You are doing it WRONG!

    You are applying the totally wrong tool to your problem: A function that never was written for "database sanitization" (which is the wrong idea anyway; use prepared statements for database queries and use <FONT face="Courier New">htmlspecialchars</FONT> for generating HTML).

    While it appears to work for the usual SQL injection example, what if your code looks like this

    <FONT face="courier new,courier">$userName = htmlspecialchars(<FONT color=#000000>$_GET['userName']</FONT>, ENT_QUOTES);</FONT>

    <FONT face="courier new,courier">$pin = htmlspecialchars(<FONT color=#000000>$_GET['pin']</FONT>, ENT_QUOTES);</FONT>

    <FONT face="courier new,courier">$sql = "SELECT userName, sensitiveData FROM Users WHERE userName='$userName' AND pin=$pin";</FONT>

    Of course the pin in your database is an INTEGER. It's PHP code.  It's PHP code using htmlspecialchars to <FONT color=#000000>sanitize parameters for database queries, so more WTFs are guaranteed!</FONT>

    <FONT color=#000000>So now let's watch user Bobby Tables filling out your dialog. Bobby Tables is a bit forgetful, he can't remember his PIN. </FONT>

    <FONT color=#000000>Was it 1234? But wasn't that the luggage? Or was it 1001? The computer is intelligent, it will find out (and forgive my nervous finger on the SHIFT key!)</FONT>

    <FONT color=#000000 face="courier new,courier">USERNAME: Bobby Tables </FONT>

    <FONT color=#000000 face="courier new,courier">PIN: 9999 OR 1=01</FONT>

    <FONT color=#000000>And now we see the following query send to the database:</FONT>

    <FONT color=#000000 face="courier new,courier">SELECT userName, sensitiveData FROM Users WHERE userName='Bobby Tables' AND pin=9999 OR 1=01</FONT>

    <FONT color=#000000>And blam: Bobby Tables sees sensitiveData from EVERY User in the database!</FONT>

    <FONT color=#000000>(Yes, checking if pin is an integer is a great idea. But you already relied on "no way nor anyone who would find a way to SQL inject anything through htmlspecialchars", so i don't really believe you do this).</FONT>



  • Again, PHP is TRWTF. Why are people continually bitten by this fact?


  • Considered Harmful

    @no laughing matter said:

    <font face="courier new,courier">$sql = "SELECT userName, sensitiveData FROM Users WHERE userName='$userName' AND pin=$pin";</font>

    Of course the pin in your database is an INTEGER. It's PHP code.  It's PHP code using htmlspecialchars to <font color="#000000">sanitize parameters for database queries, so more WTFs are guaranteed!</font>

    You don't need to contrive some weird integer password for this. Take

    select article_title, article_text from article where article_id = $id
    . Now substitute
    $id = '-1; select TABLE_SCHEMA, TABLE_NAME from information_schema.tables'
    . Now they know all the tables you have. And a query later they know the columns. And a few (hundred) queries later, they have a full dump of all the data in every table.

    You can even create helper functions like concat in PostgreSQL, which help you cram all the data into a single field. Use GUIDs or something for the separator between fields and you can automate the whole thing. Route each request through Tor and change routes every so often so there's no concentration of traffic from a single endpoint. *cough*No I've never done this, why do you ask?



  • @mikeTheLiar said:

    Again, PHP is TRWTF. Why are people continually bitten by this fact?

    No, retards are TRWTF. PHP is fine if written by non-retards. Is C# "super duper awesome" even when written by a retard?


  • Discourse touched me in a no-no place

    @gu3st said:

    No, retards are TRWTF. PHP is fine if written by non-retards. Is C# "super duper awesome" even when written by a retard?
    The problem with PHP, at least historically, is that it put roadblocks in the way of doing things right and consistently, and paved a superhighway right to doing stuff badly and inconsistently. The overhang of pain and disaster is colossal; not so much a Sword of Damocles as a Thermonuclear Weapon of Edward Teller.



  • @dkf said:

    not so much a Sword of Damocles as a Thermonuclear Weapon of Edward Teller

    That is an excellent turn of phrase, well done sir.



  • @Ben L. said:

    Parameterized queries are a form of sanitization, so I guess those are right out.

    Stay in school, Ben.


  • Trolleybus Mechanic

    @Salamander said:

    @Ben L. said:
    Parameterized queries are a form of sanitization, so I guess those are right out.
    Stay in school, Ben.
     

    Sanitize, strip out bad data (single quote removed):  Input = "Bobby'; DROP TABLES=> Sanitize() => "Bobbly DROP TABLES"

    Escape/Encode, escape control characters into non-control (single quote to escaped single quote): Input = "Bobby'; DROP TABLES" => EscapeEncode() => "Bobby\'; DROP TABLES"



  • @no laughing matter said:

    You are doing it WRONG!

    thank you for the first direct answer I ever got to this question, even after asking it repeatedly many, many times over the years. that's one thing.


    @no laughing matter said:
    (Yes, checking if pin is an integer is a great idea. But you already relied on "no way nor anyone who would find a way to SQL inject anything through htmlspecialchars", so i don't really believe you do this).

    nope, i cast all the numerics, and only strings went through htmlspecialchars.

    $pin =(int)$_GET['pin'];


    still, you've got relevant point, even if it doesn't apply on my code specifically.

    @no laughing matter said:

    You are applying the totally wrong tool to your problem: A function that never was written for

    hey, we're talking PHP here, all of development in it is finding a tool that was meant to do something else, but is more useful for what you need than the tool that was designed to be used for what you need to do.



  • @joe.edwards said:

    You don't need to contrive some weird integer password for this. Take

    select article_title, article_text from article where article_id = $id
    . Now substitute
    $id = '-1; select TABLE_SCHEMA, TABLE_NAME from information_schema.tables'
    . Now they know all the tables you have. And a query later they know the columns. And a few (hundred) queries later, they have a full dump of all the data in every table.

    nice one, thanks.

    lucky me that none of the three sites I made before I started using frameworks had enough traffic or any kind of data to make them an interesting target.

    Also, funny I asked the same question about my use of htmlspecialchars on one interview, for an international company dealing in security (antivirus manufacturers), for a position of PHP coder maintaining their multi-server code, and my then-future-boss didn't even LOOK like he saw anything wrong about it.



  • @Lorne Kates said:

    Sanitize, strip out bad data[...]

    Escape/Encode, escape control characters into non-control [...]

    In addition to that, the entire point of parameterised queries is to separate the SQL from the data.
    The data is neither sanitised nor escaped in much the same way that you don't sanitise or escape function parameters in C - it just doesn't make any sense.


  • Discourse touched me in a no-no place

    @no laughing matter said:

    Of course the pin in your database is an INTEGER.
    Nice straw-man there. Personal PIN identification numbers should not actually be bare numbers since they're standing in for passwords, and the pins 00000, 000 and 0 would be, but shouldn't be, equivalent if they were stored as such. Point taken however.



  • Hey, i missed the opportunity to smuggle in a TV Tropes reference in my previous comment, so thanks for that!

    @PJH said:

    @no laughing matter said:
    Of course the pin in your database is an INTEGER.
    Nice straw-man there. Personal PIN identification numbers should not actually be bare numbers since they're standing in for passwords, and the pins 00000, 000 and 0 would be, but shouldn't be, equivalent if they were stored as such. Point taken however.

    But PIN is short for Personal Identification Number, so it should be modelled as a numeric type!

    Exactly what it says on the pintin!



  • @no laughing matter said:

    But PIN is short for Personal Identification Number, so it should be modelled as a numeric type!
     

    You have 9 posts so I can't tell yet if you're sarcastic.


  • Discourse touched me in a no-no place

    @no laughing matter said:

    Hey, i missed the opportunity to smuggle in a TV Tropes reference in my previous comment, so thanks for that!

    @PJH said:

    @no laughing matter said:
    Of course the pin in your database is an INTEGER.
    Nice straw-man there. Personal PIN identification numbers should not actually be bare numbers since they're standing in for passwords, and the pins 00000, 000 and 0 would be, but shouldn't be, equivalent if they were stored as such. Point taken however.

    But PIN is short for Personal Identification Number, so it should be modelled as a numeric type!

    So, storing '0345' as a PIN means it should be stored as 229, '0678' wouldn't be allowed and 1234' should be stored as 1234? Makes sense in a WTF sort of way I suppose....

  • Discourse touched me in a no-no place

    @dhromed said:

    @no laughing matter said:
    But PIN is short for Personal Identification Number, so it should be modelled as a numeric type!
    You have 9 posts so I can't tell yet if you're sarcastic.
    Given the TVtropes reference and use of <strike> in the anchor text, I'm guessing they are.



  • @SEMI-HYBRID code said:

    nope, i cast all the numerics, and only strings went through htmlspecialchars.

    $pin =(int)$_GET['pin'];
    <FONT face=arial,helvetica,sans-serif>hey, we're talking PHP here, all of development in it is finding a tool that was meant to do something else, but is more useful for what you need than the tool that was designed to be used for what you need to </FONT><FONT face=arial,helvetica,sans-serif>do.
    </FONT>
    <FONT face=arial,helvetica,sans-serif>Well, that's the problem i see with this approach: You must be aware of it's limitations and if you recommend it to others, they will use it as a general purpose problem solver without being aware of these limitations.</FONT>
    <FONT face=Arial>The same applies to prepared statements, too!</FONT>
    <FONT face=Arial>I had code fail on trying to insert a string containing an apostrophe through a simple INSERT statement executed as a prepared statement.</FONT>
    <FONT face=Arial>I thought "it cannot be!" and after a long investigation i found out that the table had a trigger which called a stored procedure.</FONT>
    <FONT face=Arial>This stored procedure tinkered an SQL-statement as a varchar variable, including values from my INSERT statement, to be executed via EXECUTE IMMEDIATE.</FONT>
    <FONT face=Arial></FONT> 


  • @PJH said:

    Given the TVtropes reference and use of <strike> in the anchor text, I'm guessing they are.
     

    Likely, but I'd like to hear it form the horse's ass.



  • @dhromed said:

    @no laughing matter said:

    But PIN is short for Personal Identification Number, so it should be modelled as a numeric type!
     

    You have 9 posts so I can't tell yet if you're sarcastic.

    Some more posts in the article comments, but that's another forum.

    Actually, if you read comments to this article you will find that i argue against the stupidness of storing identifier "numbers" as integers and especially the alleged performance advantages for extracting parts of the number.



  • @TimeBandit said:

    @mikeTheLiar said:
    Is anyone really surprised that something written in PHP is a steaming pile?



    Of course, if it was written in .NET it would be GOLD !
    I mean, the code would be re-written on the fly by the magic .NET compiler, optimized and made to run on any platform.


    The proof is Community Server. It's such a great product BECAUSE it's .NET. If it was written in PHP, it would be a steaming pile of shit, whoever wrote it would not make a difference.

    That's why all the top million busiest sites are built with .NET because they need performance. PHP would not scale since it is JUST SHIT !

    Proof : on those sites, IIS represent a huge 12.56% of the market !

    Okay, since some of these replies have gotten oddly personal, I think perhaps some clarification/defense is in order here.

    1. C#/.Net does not make something good. Ref: any thread I've started in the sidebar.
    2. As a matter of fact, I don't really feel that strong about .Net. I just happen to be working within that environment right now.
    3. There are plenty of languages that I don't work with that I'm perfectly fine with. Python? No problem. Go? Eh, I mainly make fun of it because it's fun to tease Ben L.
    4. Yes, a bad programmer can write shit in any language. A good programmer can work with what's available. That being said, PHP seems designed to produce bad code. The fact that [code]mysql_real_escape_string[/code] 1) exists because they fucked it up the first time and 2) is DEPRECATED because the fucked it up the second time says it all, really. Nevermind that error messages might randomly be in Hebrew. If you want a programming language in Hebrew, fine, but stick to one language.
    5. Finally, the fact that there are entire sites devoted to how bad PHP is serves as a pretty strong indicator as to the quality of a language as well. That's IE level of failure right there.

    In closing: chill out. I don't like PHP. That's not a personal attack. Just because I don't like the same thing that you might like doesn't mean that I don't like you.



  • @mikeTheLiar said:

    Nevermind that error messages might randomly be in Hebrew.
    And the Hebrew word is misspelled.



  • Discourse touched me in a no-no place

    @El_Heffe said:

    @mikeTheLiar said:
    Nevermind that error messages might randomly be in Hebrew.
    And the Hebrew word is misspelled.
    Of course it is - it's been transcribed to a latin alphabet. It should be T_פעמיי_ נקודתיים‎ (or perhaps more probably פעמיים_נקודתיים‎_T)[1]







    [1] Any problems with character encodings are probably my browser's fault.



  •  OK, I’ve never heard the term used that way. My point was that if you’re using parameterized SQL, then there is no problem if you have a student named "Robert'); DROP TABLE Students;--".



  • @Salamander said:

    @Ben L. said:

    Parameterized queries are a form of sanitization, so I guess those are right out.

    Stay in school, Ben.

    Ben was making a point about Sir Twist's comment:

    @Sir Twist said:

    If you’re worried about sanitizing your database inputs, you’ve already lost.

    Of course sanitization by using parameterized queries is a good idea. I would even venture to say that it is a best practice for preventing SQL injection attacks. Don't be a dick by taking his sarcasm out of context.

    Then again, the tag you gave your post indicates you may not even understand what a parameterized query is. In case you don't, here's a little lesson. Let's say you want to select a records from a table called Players with a given name. Using a parameterized query, you would create a parameter, say @Name, and give it the value of your user input. Then you would use it as follows:

    SELECT * FROM Players WHERE Name = @Name

    That way, you aren't directly using the user input, and you don't have to worry if someone enters "John Smith'; DROP Players", because your query will just return records with a name of "John Smith'; DROP Players". It's not very likely they'll get anything back, but your data will remain safe.

     Stay in school, Salamander.



  • He knows what paramaterized queries are, he (and I) just doesn't consider that to be "sanitization".



  • @RangerNS said:

    He knows what paramaterized queries are, he (and I) just doesn't consider that to be "sanitization".


    What else would you call it?



  • Paramaterized queries does not change the input data, it deals with it in a safe way.

    I can sanitize many biological specimens with bleach (or a bullet), but dealing with them live, and protected somehow, is, depending on how you want to poke at them, a different thing.



  • @Snooder said:

    What else would you call it?

    I wouldn't call it anything.
    The entire point of parameterised queries is that you divide it into two parts: data and code. You supply data for the code to operate on at the appropriate time.
    Consider JavaScript's Function constructor:

    var strcat = Function('a', 'b', 'return "" + a + b');
    

    strcat('123;//', '456');



    Results in the string '123;//456'. Neither argument is being escaped or sanitised, yet it still behaves exactly as you would expect it to.

    The entire concept of sanitisation/escaping doesn't apply. It's like asking someone "What did you name your dog?" when they have never owned a dog.



  •  I can completely understand why some people say that PHP is TRWTF when we have wordpress copy and paste kiddys.



  • @Snooder said:

    @RangerNS said:

    He knows what paramaterized queries are, he (and I) just doesn't consider that to be "sanitization".


    What else would you call it?

    “Paramaterized queries”


     



  • @Salamander said:

    @Snooder said:

    What else would you call it?

    I wouldn't call it anything.
    The entire point of parameterised queries is that you divide it into two parts: data and code. You supply data for the code to operate on at the appropriate time.
    Consider JavaScript's Function constructor:

    var strcat = Function('a', 'b', 'return "" + a + b');
    strcat('123;//', '456');
    

    Results in the string '123;//456'. Neither argument is being escaped or sanitised, yet it still behaves exactly as you would expect it to.

    The entire concept of sanitisation/escaping doesn't apply. It's like asking someone "What did you name your dog?" when they have never owned a dog.

     



    Ah, your working definition of "sanitized" is when the string itself is mutated. I've generally heard it used to describe when a string is "made clean" for some purpose, even if the string comes back exactly the same from the process.

     



  • This is a pedantic linguistic issue... but then, of course it is. This is TDWTF.

    Perl got it right at least conceptually: the state of the variable is being blessed (or not); how you bless it is up to you.


  • Discourse touched me in a no-no place

    @Snooder said:

    @RangerNS said:
    He knows what paramaterized queries are, he (and I) just doesn't consider that to be "sanitization".
    What else would you call it?
    “Avoiding conflating trusted code and untrusted data, and so not doing it the moronic way in the first place.” But maybe that's just me.

    There are times when treating code as data is really neat. Dealing with stuff from users that you might not trust is definitely not the time for such fun and games.



  • @dkf said:

    “Avoiding conflating trusted code and untrusted data, and so not doing it the moronic way in the first place.”

    TRWTF is that you're trusting PHP code...


  • Discourse touched me in a no-no place

    @Buttembly Coder said:

    TRWTF is that you're trusting PHP code...
    There's nothing about PHP that couldn't be fixed by investing in advanced physics, building a working time machine, going back in time to the early '90s, and killing the developers of PHP and all their families.


Log in to reply