Level 33 C++ sourcerer. https://about.me/marek.knapek

  • 6 Posts
  • 4 Comments
Joined 1 year ago
cake
Cake day: June 29th, 2023

help-circle
  • 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?



  • 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/





  • 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.