Security Vulnerability Testing?

Remoting SDK
1

Hello all,

I’ve been asked by a customer to test (& report) my Delphi custom data-abstract server for security vulnerabilities. I’ve always attempted to follow the usual rules, e.g. no string concat for SQL, all service (apart from login) require session etc.

Has anyone done this and could offer some further advice?

Many thanks

2

Hi Stuart,

See in my opinion you should Try, To test your Delphi custom Data Abstract server for security vulnerabilities, you can follow these steps:

Input Validation: Ensure all user inputs are validated and use parameterized queries to prevent SQL injection.
Session Management: Make sure sessions are secure and regenerate session IDs after login.
Access Control: Check that users can only access resources they are authorized to.
Encryption: Encrypt sensitive data both in transit and at rest using strong protocols like TLS.
Code Review: Review your code for security issues and use static analysis tools like SonarQube.
Penetration Testing: Use tools like OWASP ZAP and Burp Suite to find vulnerabilities by simulating attacks.
Security Headers: Set proper security headers on your server.
These steps will help you identify and fix potential security issues. hope the above will be helpful.

Thanks,
@marksmit991

2 Likes
3

Hi,

some “generic” ideas:

  • don’t send direct sql from client-side. use DA SQL instead.
  • you can specify own Dynamic Where for each table.
    Untitled
    Untitled841×723 26 KB
  • you can restrict access to services based on server component [and his port]. for example, Admin service can be accessed from 8100 port and cannot be from 8099 port. see more at Service Group feature
  • each group of users should have personal service. i.e. each “department” has own service.
  • you can use Roles feature so each group of users can access only to own service and can’t to others services.
  • you can use Message Envelopes. for some cases you can create own envelope based on own rules like Caesar cipher - Wikipedia or something similar.
  • You can set message.MaxStringSize. it will disallow to read very big string. it can be usable with broken requests
  • some server components have limitation for request size, like TROHTTPServer.MaxPostData
2 Likes
4

Thanks Mark & Evgeny.

Is there anything that can be done to prevent DoS attacks - e.g. is there anyway to mitigate being flooded with requests ?

Thanks again

5

Hi,

You can look for prevent DoS attacks in google/yahoo/etc .

Google suggested to me these links:

1 Like
6

As a general note, I have started to no longer host my RO/DA servers (ours, personal, and side projects I am involved with) directly on an open custom port (and worrying about setting up TLS/https for them); instead I run them using plain HTTP on an internal port, use nginx as frontend, and worry about open ports, domain names, TLS (lets encrypt is your friend) & co only on the nginx level. It makes many ting a lot easier and it should allow you to use whatever nginx offers for request throttling or other DDoS prevention tools (not an area I have needed to explore myself yet, thankfully), instead of burning tyour server app with it.

Since nginx by its very nature is used exponentially more on servers world wide than RO/DA, it will always be more robust, and more quick to be updated to new threats and new technologies in general.

2 Likes
7

Thanks again - that’s interesting information marc/Evgeny; the company requesting the tests are hosting the server and have control over the infrastructure surrounding it, so I can, er, ‘delegate’ that.

Some useful information for me - thanks all.

Have a good weekend

1 Like
8

thanx, you too!