3 ms·

What stacks eliminate encoding vulnerabilities ? And are there any stacks that even protect you from writing bad business logic , if that's even possible ?

by petra 10y ago

nickpsecurity 10y ago
You can use secure parser generators like HAMMER or Nail for encodings. If it's about integration, you can use something like ZeroMQ. Far as eliminaging logic errors, you can make a lot of progress on that using formal specifications combined with modular code that matches them well. That's how med-high assurance was done. Some companies also specify domain rules in formal logic then implement them in Prolog or Mercury. You will have a hard time straying from intended logic when executing the logic itself. ;) Toolkits like Allegro CL and sklogic's DSL scheme let you mix and match things like LISP for power, ML for safety, and Prolog for logic execution. Really niche stuff in industry, though.
jerf 10y ago
Using something like Shakespeare for Haskell makes it very difficult to write HTML that is incorrectly encoded without doing it on purpose: https://hackage.haskell.org/package/shakespeare https://hackage.haskell.org/package/shakespeare More conventionally, even something like Go's html/template [1], though I believe it uses a technique that can ultimately be fooled, is much harder to write accidental encoding vulnerabilities into. If you do the natural thing in the templates, the templates do the right thing. Business logic errors I don't expect to be prevented by, well, anything. Oh, you can do some work to prevent certain sorts of errors with type systems, but a lot of business logic errors often start in the requirements, or the translation of the requirements into the code. Nothing will ever stop us from taking fuzzy requirements and translating them into wrong code, even if we can at least ensure the wrong code doesn't crash, corrupt memory, expose encoding errors, or violate simple invariants.

What stacks eliminate encoding vulnerabilities ? And are there any stacks that even protect you from writing bad business logic , if that's even possible ?

by petra 10y ago

What stacks eliminate encoding vulnerabilities ? And are there any stacks that even protect you from writing bad business logic , if that's even possible ?

nickpsecurity 10y ago

You can use secure parser generators like HAMMER or Nail for encodings. If it's about integration, you can use something like ZeroMQ. Far as eliminaging logic errors, you can make a lot of progress on that using formal specifications combined with modular code that matches them well. That's how med-high assurance was done. Some companies also specify domain rules in formal logic then implement them in Prolog or Mercury. You will have a hard time straying from intended logic when executing the logic itself. ;) Toolkits like Allegro CL and sklogic's DSL scheme let you mix and match things like LISP for power, ML for safety, and Prolog for logic execution. Really niche stuff in industry, though.

jerf 10y ago

Using something like Shakespeare for Haskell makes it very difficult to write HTML that is incorrectly encoded without doing it on purpose: https://hackage.haskell.org/package/shakespeare https://hackage.haskell.org/package/shakespeare More conventionally, even something like Go's html/template [1], though I believe it uses a technique that can ultimately be fooled, is much harder to write accidental encoding vulnerabilities into. If you do the natural thing in the templates, the templates do the right thing. Business logic errors I don't expect to be prevented by, well, anything. Oh, you can do some work to prevent certain sorts of errors with type systems, but a lot of business logic errors often start in the requirements, or the translation of the requirements into the code. Nothing will ever stop us from taking fuzzy requirements and translating them into wrong code, even if we can at least ensure the wrong code doesn't crash, corrupt memory, expose encoding errors, or violate simple invariants.