4 ms·

We already changed the "process" in order to eliminate bugs two decades ago... What security issues have been recently solved by programming languages? Things

by blub 7y ago

We already changed the "process" in order to eliminate bugs two decades ago... What security issues have been recently solved by programming languages? Things like unsafe memory usage are an anomaly. Most other security issues can't even be represented at the PL level.

staticassertion 7y ago
Every security issue can be represented at the language level. It's just a matter of building a more constrained, domain specific language, that encodes the requisite security properties.
- blub 7y ago
  And then it's a matter of begging others to use the said constrained language, because it's a PITA to use :)
  - astrobe_ 7y ago
    Well, yes. What people forget to mention is that security always has a price. That's why less safe languages are more popular.
    - staticassertion 7y ago
      Less safe languages are not more popular at all. Memory safety was a huge selling point for languages like Java, Python, etc. The cost in those cases is performance. The cost is offset massively by productivity. It's less about direct costs and more about constraints and priorities.
JamesBarney 7y ago
LINQ in C# reduces how much SQL people write in C#, which reduces the number of sql injection attack surfaces.
- jtdev 7y ago
  It’s incredibly simple to parameterize plain ADO.NET SQL statements as well; LINQ and EF are not required to prevent SQL injection when working in C#/.Net.
  - JamesBarney 7y ago
    I guess I wasn't clear. Most advances in security don't make it much easier to write secure code. They make it hard to write insecure code. And I'm not arguing LINQ makes it much easier to write secure code(that was already pretty easy), but it makes it much harder to write insecure code. Imagine you tasked two rooms of 100 jr devs to query a database, one with EF, one with ADO.NET. Do you honestly think the same percentage of jr devs would have written code open to SQL injection? string queryString = "SELECT ProductID, UnitPrice, ProductName from dbo.products " + $"WHERE ProductName = {userSuppliedName} " + "ORDER BY UnitPrice DESC;"; SqlCommand command = new SqlCommand(queryString, connection); SqlDataReader reader = command.ExecuteReader(); I've met a ton of devs who would write this code without thinking(some even with quite a few years of experience.)

by blub 7y ago

staticassertion 7y ago

Every security issue can be represented at the language level. It's just a matter of building a more constrained, domain specific language, that encodes the requisite security properties.

blub 7y ago
And then it's a matter of begging others to use the said constrained language, because it's a PITA to use :)
- astrobe_ 7y ago
  Well, yes. What people forget to mention is that security always has a price. That's why less safe languages are more popular.
  - staticassertion 7y ago
    Less safe languages are not more popular at all. Memory safety was a huge selling point for languages like Java, Python, etc. The cost in those cases is performance. The cost is offset massively by productivity. It's less about direct costs and more about constraints and priorities.

JamesBarney 7y ago

LINQ in C# reduces how much SQL people write in C#, which reduces the number of sql injection attack surfaces.

jtdev 7y ago
It’s incredibly simple to parameterize plain ADO.NET SQL statements as well; LINQ and EF are not required to prevent SQL injection when working in C#/.Net.
- JamesBarney 7y ago
  I guess I wasn't clear. Most advances in security don't make it much easier to write secure code. They make it hard to write insecure code. And I'm not arguing LINQ makes it much easier to write secure code(that was already pretty easy), but it makes it much harder to write insecure code. Imagine you tasked two rooms of 100 jr devs to query a database, one with EF, one with ADO.NET. Do you honestly think the same percentage of jr devs would have written code open to SQL injection? string queryString = "SELECT ProductID, UnitPrice, ProductName from dbo.products " + $"WHERE ProductName = {userSuppliedName} " + "ORDER BY UnitPrice DESC;"; SqlCommand command = new SqlCommand(queryString, connection); SqlDataReader reader = command.ExecuteReader(); I've met a ton of devs who would write this code without thinking(some even with quite a few years of experience.)