• 0 Posts
  • 105 Comments
Joined 9 months ago
cake
Cake day: September 27th, 2023

help-circle


  • If I wanted a WYSIWYG field I’d probably still use markdown. I could add the buttons to properly inject markdown symbol and use a JS markdown renderer for the text field. Tbh I’d be amazed if there weren’t at least a dozen out-of-the-box packages that included a live rendered text area with a widget array.

    In this instance I’m not advocating for markdown as a user interface but just using it as a quick and dirty markup language. Be aware that if you turn to HTML, you’d be adopting responsibility for a lot of non-trivial security issues. If the customization went beyond markdown (into, for instance, fonts) you’d need a more complex solution so you’d likely want to investigate other tag or boundary marker based markup languages out there. Markdown is just simple and has ten billion implementations out there.


  • That is a very unlikely approach.

    Rich text in the modern world is almost exclusively solved by using markdown because it’s such a trivial solution.

    In previous words it was usually solved either using range tags (similar to HTML, sometimes literally HTML, more often custom stuff) or embedded boundary markers (something that marked a new boundary and then had a full definition of the styles to follow, sometimes omitting styles that didn’t change, often times in some insanely dense binary format for predictable scanning).

    Usually, it’s more sane to embed formatting in the string itself rather than having styling separately defined (i.e. CSS, kinda). Because otherwise storage would be a huge pain and reading would require a lot of non-consecutive disk scans.








  • Is this related to highly sensitive PII (like hippa or whatever covers local health-care record treatment)? If so, I’d strongly suggest not doing anything and seeking a remedy from contractual obligations by the vendor (i.e. seek HIPPA Ready software or a vendor willing to make that promise).

    If not, you’ll definitely want to focus on data persistence and transmission.

    Make sure there aren’t outgoing network calls to fixed locations (if they’re for error reporting to the vendor you can either ask if they can disable the reporting, black hole the reporting with network configuration or carefully inspect the way data gets to that reporting and ensure user data can’t be captured - a common oversight being logging function parameters).

    Make sure the persistence is secure by looking at the main persistence module (i.e. a database or flat file) to make sure unnecessary information isn’t being stored, verification only information is being written to persistence through one way hashes, and data that should be two-way encrypted is. Then double check the same stuff with regards to secondary persistence methods - again a huge issue here is logging.

    Those two points are where I’d suggest focusing the majority of your effort but, back to the hippa part, make sure you’re comfortable doing this. It’s pretty easy for auditors to be the fall guys if something goes wrong so if you want to be careful one approach is to carefully document what you’ve checked for and how you checked for them then get someone above you to sign off that your level of auditing was sufficient - if shit ever does hit the fan you’ll be less exposed.


  • For what purposes are you auditing this software. Auditing is always done to prove something is appropriate for some usage and what that audit should involve depends on that usage and, additionally, factors of trust between you and the author.

    Would you be comfortable supplying some additional information about what you (or whoever asked you to run the audit) expects out of the audit.