this post was submitted on 25 May 2026
1301 points (99.2% liked)

Programmer Humor

31576 readers
2101 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] Kenny2999@lemmy.world 226 points 1 day ago (3 children)

My day has come!!!

[–] deadbeef79000@lemmy.nz 8 points 1 day ago (3 children)

Don't sanitise inputs. Reject non-conforming inputs entirely.

But otherwise: yes.

[–] nonagonOrc@lemmy.world 6 points 23 hours ago

No fuck both of those, just use prepared statements so user input can't be interpreted as SQL.

[–] Valmond@lemmy.dbzer0.com 8 points 1 day ago (1 children)

And end up having loads of valid requests rejected 😁

[–] deadbeef79000@lemmy.nz 3 points 1 day ago (2 children)

If they were valid they wouldn't be rejected.

[–] AzuraTheSpellkissed@lemmy.blahaj.zone 5 points 15 hours ago (1 children)

I've managed webapps which rejected "René". Heck, my deadname has a hyphen, which often is considered illegal

[–] deadbeef79000@lemmy.nz 2 points 14 hours ago

Which means the app was crap. Rather the rules it used to validate a valid name are garbage.

Usually because someone tried to be too strict. E.g. names are space delimited A-Za-z strings, rather than just accepting any old Unicode string and safely processing it (e.g. with an SQL prepared statement).

I've had websites reject email addresses with one of the newish TLD's because someone decided they new how to validate an email address (it's more a more flexible spec than you might think).

[–] Valmond@lemmy.dbzer0.com 4 points 1 day ago (2 children)

Well then someone with a Tagalog name gets caught in your filter...

I mean if it's "perfect" they yes, it'll work, but in production...

Also, you sometimes want to be able to store "1); Drop table abc;" in your database, I mean how do you otherwise store this comment right here? Sanitizing.

[–] anton@lemmy.blahaj.zone 4 points 1 day ago

I agree with everything in your comment except the last word. Only sanitize in cases where there isn't a better option like html or terminal escape sequences. SQL had prepared statements, which are better.

[–] deadbeef79000@lemmy.nz 2 points 23 hours ago* (last edited 14 hours ago)

That's conforming (to what ever criteria). Send me a UTF-16 string of at most 100 code points. Send me a 7-bit ASCII string of only A-Z0-9. Reject anything that doesn't comform.

sanitizing is trying to clean an input. That's "lemme just double escape some special characters" or stripping/replacing/encoding characters or truncating strings, coercing types. Don't do this, your sanitization code will have bugs or edge cases.

[–] ivanafterall@lemmy.world 5 points 1 day ago (1 children)
[–] akunohana@piefed.blahaj.zone 20 points 1 day ago (4 children)

How would you do this in C? I'm a beginner. Does it entail checking/disallowing certain characters and data types? What? 😃

[–] copacetic@discuss.tchncs.de 18 points 1 day ago* (last edited 1 day ago)

If you use the SQLite C API like this

    char query[256];
    snprintf(query, sizeof(query),
             "SELECT * FROM users WHERE username = '%s'", username);
    int rc = sqlite3_exec(db, query, NULL, NULL, &err_msg);

and someone enters Robert'; DROP Table Students;-- as username, it deletes the table Students.

    const char *sql = "SELECT * FROM users WHERE username = ?";
    int rc = sqlite3_prepare_v2(db, sql, -1, &stmt, NULL);
    if (rc != SQLITE_OK) {
        fprintf(stderr, "Failed to prepare statement\n");
        return;
    }
    sqlite3_bind_text(stmt, 1, username, -1, SQLITE_STATIC);

Using this "prepared statement" and "bind", your code is secured against such SQL injection attacks.

[–] vrek@programming.dev 34 points 1 day ago (1 children)

How do you sanitize your inputs or how do you exploit inputs which are not sanitized.

[–] akunohana@piefed.blahaj.zone 29 points 1 day ago (1 children)

Santize inputs.

I'll get back to you on exploits when I can write something that throws zero compilation errors. 😈

[–] vrek@programming.dev 28 points 1 day ago (2 children)

Couple big things are 1. Only accept reasonable characters, on a white list instead of rejecting bad characters based on a black list. This will mean you are less likely to forget to block /0 for example. 2. Understand how strings work and ensure both reading and writing to that string doesn't extend beyond the end of memory allocated for the string. For example do you understand what the /0 would do to a string your program accepts?

[–] brbposting@sh.itjust.works 1 points 8 hours ago (1 children)

Is it easy for a good developer to allow new lines without any extra security risk exposure?

Sometimes e.g. a government form will remove new lines, though perhaps sometime they intend to reduce length.

[–] vrek@programming.dev 0 points 1 hour ago* (last edited 1 hour ago)

Depends...how well written the form is. Often stuff like this is pushed to libraries who have covered all the gotchas but you have to be careful not to get into dependency hell. Understand where to use them and not. For example don't use left_pad but also don't make your own encryption.

How easy is it to allow new lines,very easy. The important part is only accepting new lines e.g. /r/n a well made form can include extra functions but anything not defined should be denied.

Also consider you likely should not accept a username with a semi-colon in it...

[–] akunohana@piefed.blahaj.zone 8 points 1 day ago (1 children)

Sic! Thanks! I'll work on this this weekend! 😊

[–] vrek@programming.dev 12 points 1 day ago

Keep in mind, the lowercase and uppercase letters are in continuous blocks on the ASCII table so you can can use that to verify if a char is a letter without doing an incredible long chain of if else statements.

[–] jaybone@lemmy.zip 16 points 1 day ago (1 children)

Many languages like C, Java, Python, etc allow you to construct SQL queries or SQL statements, where SQL is its own language used to communicate with a database, like Oracle or MySql, or Postgres or MSSQL. One way to do this is to construct a string in your language using whatever string functions, concatenation etc available in your language. The problem occurs because usually you want some kind of user input as one of the parameters in your sql query, in order to fetch the correct records the user is asking for. Like say a record ID or name. If you do not properly sanitize that ID or name which originally comes from some type of user input, then a malicious user could carefully craft an ID or name which includes their own SQL and other special characters, which will interfere with the query you intended to construct, and instead do something malicious. Like delete records or obtain records the user is not supposed to have access to.

There are many ways to guard against this, and you should learn about this when you start working with SQL and databases. It’s called a SQL injection.

There is another type of code injection which can occur if you are making exec() calls (or whatever your language uses) to run shell commands. Similar caution should be taken there.

[–] thesystemisdown@lemmy.world 6 points 1 day ago (1 children)

I know what I'm dealing with when I see a query that isn't using a prepared statement.

[–] jaybone@lemmy.zip 3 points 1 day ago

I mean a prepared statement is still created with a string.

But you definitely want to be using bind parameters with your prepared statements. Not only for security but also potentially performance improvements.

[–] LovableSidekick@lemmy.world 5 points 1 day ago* (last edited 1 day ago)

You wouldn't - what they're describing is called "SQL injection" - a way to fool poorly written web server code (regardless of what language it's writen in) into executing SQL code. The poorly written server code takes what's entered in a form field on a web page and pastes it into a skeleton of a SQL statement - in this case the text in the input field is SQL that ends the intended statement, followed by a new statement that deletes a table. For this to even work, the SQL skeleton on the server would have to be structured in just the right way so the modified version with the pasted-in text still makes sense. For this reason, hackers attempting SQL injection usually have to do a lot of trial and error to get something to happen. The only way it can work at all is if the server software handling the web page sends SQL commands to a database server as text, as if they're being typed in, and the server executes them. You can't inject C in this way because unlike SQL, C code isn't just executed, C programs have to be precompiled.