You can always take a look how for example Windows 3.11 and earlier did it for their *.rtf file format and their "write.exe" editor / viewer / renderer (if you want to call it that way).

You have stack buffer out of bounds write. On line 52 you declare h an array of 70 unsigned ints. On line 57 you store reference to such array. Later, on line 35 you write out of bounds, one element past end of the array. The _SPR_history[i] writes to _SPR_history[70]. Created an issue: https://github.com/X64X2/sh/issues/1

Doesn't depend on programming language but something with visual debugger. You know that stuff when you can see current line of your source code highlighted, press a key to step into, step over and so on. You can see values inside your variables. You can also change your variables mid-run right form the debugger.

Because you spend 20% of your time writing bugs and the other 80% debugging them. At least make it pleasant experience (no printf-style debugging).

Back in the day I was using Turbo Pascal, Delphi, Visual Basic, C#, Java, PHP with Zend, Java Script, today I'm using Visual C++.

The interview starts ... the interviewer asks me "Tell me about yourself." ... I respond "Did you receive my CV? I put all important details about me ... right there. What questions do you have about my past jobs?" The interviewer encourages me again to tell him about myself, my past projects, etc. ... Me: Awkward silence. ... Me to myself: Dafuq? Should I read the CV from top to bottom OR WHAT?

Yes, but (there is always a but) it does not apply if you implement off-line encryption. Meaning no on-line service encrypting / decrypting attacker provided data (such as SSL / TLS / HTTPS). Meaning if you are running the cipher on your own computer with your own keys / plaintexts / ciphertexts. There is nobody to snoop time differences or power usage differences when using different key / different ciphertext. Then I would suggest this is fine. The only one who can attack you is yourself. In fact, I implemented AES from scratch in C89 language, this source code is at the same time compatible with C++14 constexpr evaluation mode. I also implemented the Serpent cipher, Serpent was an AES candidate back then when there were no AES and Rijndael was not AES yet. The code is on my GitHub page.

std::vector::reserve + std::vector::push_back in loop is sub-optimal, because push_back needs to check for re-allocation, but that never comes.

std::vector::resize + std::vector::operator[] in loop is also sub-optimal, because resize default-initializes all elements only to be overwritten soon anyway.

This article's author suggests push_back_unchecked.

I suggest std::vector::insert with pair of random access iterators with custom dereference operator that does the "transform element" or "generate element" functionality. The standard will have resize_and_overwrite hopefully soon.

Moar discussion:

https://codingnest.com/the-little-things-the-missing-performance-in-std-vector/

https://twitter.com/horenmar_ctu/status/1695823724673466532

https://twitter.com/horenmar_ctu/status/1695331079165489161

https://www.reddit.com/r/cpp/comments/162tohr/the_little_things_the_missing_performance_in/

https://www.reddit.com/r/cpp/comments/162tohr/the_little_things_the_missing_performance_in/jy21hgd/

https://twitter.com/basit_ayantunde/status/1644895468399337473

https://twitter.com/MarekKnapek/status/1645272474517422081

https://www.reddit.com/r/cpp/comments/cno9ep/improving_stdvector/

Another alternative to C++ exceptions (instead of return code) is to use global (or thread local) variable. This is exactly what errno that C and POSIX are using or GetLastError what Windows is using. Of course, this has its own pros and cons.

Makes sense, how would you represent floor(1e42) or ceil(1e120) as integer? It would not fit into 32bit (unsigned) or 31bit (signed) integer. Not even into 64bit integer.

Oversimplified:

• You have your current OS, text editor, compiler.
• You write code of the new improved OS using your current OS, text editor.
• You compile the code (text file), compilation yields the new OS or the new kernel (binary file).
• You replace (overwrite) your current kernel by the new kernel (current OS by new OS). This is possible, because while the OS is running it is in RAM not touching the disk.
• You restart.
• BIOS loads the new OS from disk to RAM and executes it.
• tada.wav

More questions:

• How to update BIOS? Answer: The same.
• How the first OS, text editor and compiler were created? Answer: The same. Using more primitive OS, text editor and compiler each step into the past. At the beginning there were toggle switches, punch cards, punch ribbon strips or similar.

The same style of question would be: How to create a hammer if in order to create a hammer you need a hammer? How was the first hammer created? Answer: By more primitive hammer, or something that is no hammer, but almost works as a hammer.

For more info read about bootstrapping compilers. Or trusting the trust by Ken Thompson.

And that JavaScript has access to cookies, that’s just a basic part of how web browsers work. Lemmy can’t do anything to prevent that.

Yes and No. Cookies could be accessed by JS on the client. BUT. When the cookie is sent by the server with additional HttpOnly header, then the cookie cannot be accessed from JS. Look at Lemmy GitHub issue, they discuss exactly this. Lemmy server absolutely has power to prevent this.

Again, Lemmy can’t do anything about that. Once there’s a vulnerability that allows an attacker to inject arbitrary JS into the site, Lemmy can’t do anything to prevent that JS from making requests.

I believe they can. But I'm not sure about this one. The server could send a response preventing the web browser to request content from other domains. Banks are using this. There was an attack years ago when attacker created a web page with i-frame in it. The i-frame was full screen to confuse the victim it is actually using the Banks site and not the attacker site. The bank web site was inside the inner i-frame, the code in the outer frame then had access to sensitive data in the inner frame. I believe there are HTTP response headers that instruct the web browser to not allow this. But I'm not sure I remember how exactly this works.

completely independent backend

Yes, it would be more costly, but more secure. It is trade-off, which one is more important to you? In case of chat/blog/forum app such as Lemmy I prefer cheap, in case of my Bank website I prefer secure.

Oh I forgot another line of defense / basic security mitigation. If a server produces an access token (such as JWT or any other old school cookie / session ID), pair it with an IP address. So in case of cookie theft, the attacker cannot use this cookie from his computer (IP address). If the IP changes (mobile / WiFi / ADSL / whatever), the legitimate user should log-in again, now storing two auth cookies. In case of another IP change, no problemo, one of the stored cookies will work. Of course limit validity of the cookie in time (lets, say, keep it valid only for a day or for a week or so).

So what happened:

• Someone posted a post.
• The post contained some instruction to display custom emoji.
• So far so good.
• There is a bug in JavaScript (TypeScript) that runs on client's machine (arbitrary code execution?).
• The attacker leveraged the bug to grab victim's JWT (cookie) when the victim visited the page with that post.
• The attacker used the grabbed JWTs to log-in as victim (some of them were admins) and do bad stuff on the server.

Am I right?

I'm old-school developer/programmer and it seems that web is peace of sheet. Basic security stuff violated:

• User provided content (post using custom emojis) caused havoc when processing (doesn't matter if on server or on client). This is lack of sanitization of user-provided-data.
• JavaScript (TypeScript) has access to cookies (and thus JWT). This should be handled by web browser, not JS. In case of log-in, in HTTPS POST request and in case of response of successful log-in, in HTTPS POST response. Then, in case of requesting web page, again, it should be handled in HTTPS GET request. This is lack of using least permissions as possible, JS should not have access to cookies.
• How the attacker got those JWTs? JavaScript sent them to him? Web browser sent them to him when requesting resources form his server? This is lack of site isolation, one web page should not have access to other domains, requesting data form them or sending data to them.
• The attacker logged-in as admin and caused havoc. Again, this should not be possible, admins should have normal level of access to the site, exactly the same as normal users do. Then, if they want to administer something, they should log-in using separate username + password into separate log-in form and display completely different web page, not allowing them to do the actions normal users can do. You know, separate UI/applications for users and for admins.

Am I right? Correct me if I'm wrong.

Again, web is peace of sheet. This would never happen in desktop/server application. Any of the bullet points above would prevent this from happening. Even if the previous bullet point failed to do its job. Am I too naïve? Maybe.

Marek.