New answers tagged

0

The MRN (or patient id) itself in the URL is not a problem. athenahealth's REST-based APIs take patient ids directly in the URLs, and I'm guessing they have better lawyers than you do. The problem is if the URL itself, or use of your service in general would allow someone to imply something about the patient. For example, if you have URLs like ...


7

Usually, there are two kinds of exceptions: Expected exceptions, like invalid input values; or authentication failure; or asking for non-existing object. So you can (and should) be prepared to deal with this kind gracefully, with descriptive and documented error code and message. There is no point of stack trace in this case. Internal (or unexpected) ...


4

It is a problem of usability vs. security. An API, specially a REST one, should be friendly, self-documented. This includes giving friendly errors indicating the exact error, possible cause, stack, etc. In the other hand think that friendly is risky... So the answer is: Yes, it is a security problem. The information will help a potential attacker to know ...


22

The API should not expose any internal information, i.e stack traces or similar. As you really noticed they might leak information which might be used to attack the implementation. Moreover they are usually only relevant for the developer of the API and not the user of the API. These users expect proper error messages anyway and not some strange message ...


3

If you enable SSL/TLS on the server side, the client has to be able to "speak SSL/TLS" too. Otherwise, the connection will end up being reset. Just changing a web-service to use "https" does not auto-magically change all applications communication encrypted. This is a shared protocol. If I suddenly goes speaking French but you only understand English, ...


1

If you configure the server to redirect HTTP to HTTPS, you shouldn't need to modify the application code whatsoever (assuming it will follow a redirect). However, when the request is first made, it will not be encrypted. An attacker could man-in-the-middle or passively sniff the connection in order to read request data or even prevent it from redirecting to ...


0

Just because you add https to your web server does not mean that you have to remove http. For example, this very page is available both over http, and over https. While it's certainly a good idea to migrate your Android app to use https, you don't have to do it right away: offer both!


1

We are working in this domain for some time. As you've already mentioned - there's a difference between the technical signature (so the systems/databases can rely the data integrity is ensured) and legal value of data itself, where (according the legal framework) legally can sign only a 'natural' person. Each state effectively 'validates' its own citizens ...


2

Can the token stay consistent (short of revocation or manual refresh), or should the token require being "refreshed" frequently? If so, what is the feasible way to handle that? Even though if you don't want to implement OAuth I recommend to take a look at how the token handling is done in OAuth (Paragraph 1.5 and 1.5). With refresh tokens you can reduce ...


1

Because some people use RSS to publish something for a specific population, sometimes for payment. If you use a GPG key to encrypt a rss, and just your clients have that key or sub-key, you can use the best of rss and privacy.


0

A for instance of what to watch out for is illustrated by a patch released for Magento, SUPEE-5994 which addressed the following issue from exported, user entered content: Attacker can provide input that executes a formula when exported and opened in a spreadsheet such as Microsoft Excel. The formula can modify data, export personal data to another site, ...


2

While Austin is correct, it is also a risk that the file itself contains an exploit. Office applications are utterly massive and have a truly humungous attack surface area. If you have time on your hands, open up an instrumented fuzzer like American Fuzzy Lop (AFL) and run it on your Excel processor. You will find a stunning amount of very scary-looking ...


1

I think the biggest risk I can think of is if that spreadsheet contains a malicious macro. Macros in Office have been exploitable for a long time, and recently Locky and a few other cryptolockers have taken to infecting users by macros in Word. I see no reason why the macro wouldn't work in other Office programs. ...


0

I have been working with payment gateways for some time and this can be a bit confusing. First the second statement made by Elavon on within chapter 9, "Transaction security" says that the server side code will "..reduce the ability of malicious users to exploit client browser vulnerability to edit and use this data for their own fraudulent purposes." The ...



Top 50 recent answers are included