4 ms·

IMHO, people constantly introduce vulnerabilities when using high level code. Most websites are defaced this way. They're not exploiting flaws in Apache or IIS

by ksk 10y ago

IMHO, people constantly introduce vulnerabilities when using high level code. Most websites are defaced this way. They're not exploiting flaws in Apache or IIS anymore. Its the Python or PHP or Node.js application or wordpress blog or similar that doesn't sanitize user input or has a buggy web api.

jerf 10y ago
A C program talking to the web will have memory vulnerabilities, encoding vulnerabilities, and business logic vulnerabilities. A modern program talking to the web will have encoding vulnerabilities and business logic vulnerabilities. It's still progress. There are cutting edge stacks which will effectively eliminate the encoding vulnerabilities, too, leaving more-or-less just the bugs you put in. (Obviously I'm simplifying the types of vulnerabilities that exist to make a point.)
- ksk 10y ago
  Well, you could make another argument too. Given X amount of time in a day, a C programmer can't really pump out _that much_ business logic code because they're also dealing with the other lower level stuff. A high level language OTOH allows you to be more productive in terms of the business logic stuff, and therefore, I'm using a rough metric here, more lines of code, which also means more bugs in the business logic. Like you said, these are all simplifications, but I think the primary problem is that people undertake projects that are way above their competency level. Edit: If we could get some multiplayer-game like matching system where you are matched with the project depending on your skill level that would be awesome.
  - Retra 10y ago
    If you're working on a project that is not above your competency level, then you're wasting your time.
    - EpicEng 10y ago
      Yes, because the ultimate purpose of delivering software is to challenge the company's developers. /s
- 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.
kstrauser 10y ago
That's all true, but consider how many vulnerabilities we'd be seen if the programmers who wrote those applications also had to deal with pointers and memory management. You'd get the current problems plus all of the stuff that regularly snags systems programmers.
- ksk 10y ago
  I agree and we can take it further. If we had to hand encode the instructions it would cause even more bugs. The more decisions you have to make as a programmer, the more chances there are of making errors. High level languages make some decisions for you, but people still end up making mistakes. Maybe the goal should be to increase the bar at which a programmer is considered competent.
  - zzzcpan 10y ago
    I think you look at it a bit incorrectly. Those high level languages were designed not to avoid mistakes, but to push software complexity to a whole new level. You simply won't be able to get to that complexity with a lower level language, because people have limited ability to think about things and tend to fallback to solutions they can fit in their mind. Which is why you shouldn't expect high level languages to eliminate vulnerabilities, people still use their minds to the limits and make mistakes. Other approaches must be taken.
    - ksk 10y ago
      I think we agree. Its hard to encapsulate everything, so I just chose a smaller context for my argument. I was primarily thinking about resource allocation and such. A HLL does indeed allow you to compose solutions to problems in terms of higher level abstractions, which I gather is your point.

by ksk 10y ago

jerf 10y ago

A C program talking to the web will have memory vulnerabilities, encoding vulnerabilities, and business logic vulnerabilities. A modern program talking to the web will have encoding vulnerabilities and business logic vulnerabilities. It's still progress. There are cutting edge stacks which will effectively eliminate the encoding vulnerabilities, too, leaving more-or-less just the bugs you put in. (Obviously I'm simplifying the types of vulnerabilities that exist to make a point.)

ksk 10y ago
Well, you could make another argument too. Given X amount of time in a day, a C programmer can't really pump out _that much_ business logic code because they're also dealing with the other lower level stuff. A high level language OTOH allows you to be more productive in terms of the business logic stuff, and therefore, I'm using a rough metric here, more lines of code, which also means more bugs in the business logic. Like you said, these are all simplifications, but I think the primary problem is that people undertake projects that are way above their competency level. Edit: If we could get some multiplayer-game like matching system where you are matched with the project depending on your skill level that would be awesome.
- Retra 10y ago
  If you're working on a project that is not above your competency level, then you're wasting your time.
  - EpicEng 10y ago
    Yes, because the ultimate purpose of delivering software is to challenge the company's developers. /s
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.

kstrauser 10y ago

That's all true, but consider how many vulnerabilities we'd be seen if the programmers who wrote those applications also had to deal with pointers and memory management. You'd get the current problems plus all of the stuff that regularly snags systems programmers.

ksk 10y ago
I agree and we can take it further. If we had to hand encode the instructions it would cause even more bugs. The more decisions you have to make as a programmer, the more chances there are of making errors. High level languages make some decisions for you, but people still end up making mistakes. Maybe the goal should be to increase the bar at which a programmer is considered competent.
- zzzcpan 10y ago
  I think you look at it a bit incorrectly. Those high level languages were designed not to avoid mistakes, but to push software complexity to a whole new level. You simply won't be able to get to that complexity with a lower level language, because people have limited ability to think about things and tend to fallback to solutions they can fit in their mind. Which is why you shouldn't expect high level languages to eliminate vulnerabilities, people still use their minds to the limits and make mistakes. Other approaches must be taken.
  - ksk 10y ago
    I think we agree. Its hard to encapsulate everything, so I just chose a smaller context for my argument. I was primarily thinking about resource allocation and such. A HLL does indeed allow you to compose solutions to problems in terms of higher level abstractions, which I gather is your point.