Information disclosure by identifiers I'm doing a small research and I observed quite a lot of sites that reveal some private information in the ID-s that they assign. As an example I would like to point out e-commerce sites that issue auto increment ID-s for new customer orders.

By monitoring such information an adversary may obtain important marketing related data about a given site, e.g. how much orders a site makes per day, how much items are ordered, how much items per order were made. Sometimes this is sufficient for a fairly good evaluation of the site income.

To continue I saw few sites that reveal the number of their registered users in the same way. Paired with the number of new orders this creates even more statistical information.

My question is - are these problems really important? If I make a security audit where should I position such reports in the risk matrix?

This flaw should be graded by capability and exploitability.

Capability falls into the following categories:

The ability to alter information on the system that you should not be able to.
The ability to view information on the system that you should not be able to, such that a person's personal information is revealed, or credentials (or other items of information) are leaked that may aid an attacker in gaining further access to the system.
The ability to view incidental information on the system that you should not be able to, e.g. the sum of the prices of items in another user's basket on an e-commerce site.
No ability.

Exploitability falls into the following categories:

Trivially exploitable in a reliable manner, e.g. admin's user is always ID 1, or users are always given sequential IDs.
Moderately difficult to exploit, e.g. having to search through a sequence of 24-bit integers for potential identifiers.
Difficult to exploit, e.g. computing Gn+1 from G0..n, where G is a poor quality random number generator.
Impossible* to exploit, e.g. the problem equates to brute forcing a 128-bit keyspace. (* impossible = highly improbable, and way outside the cost/benefit ratio for attackers)

Note that this is not an integer scale - feel free to rate something as, for example, a 2.5 in capability.

The trick is that without exploitability, capability is pointless, and without capability, exploitability is meaningless.

In order to grade this, consider the above points, and compare your ratings to the importance of the protected resource. Also remember that sequential IDs make development easy, so the risk analysis should take this into account.

As a rule of thumb, if you're looking at anything worth protecting, and the mean average of the two numbers is less than 2, call it a high. If it's greater than two, it's entirely subjective.

I also suggest you take a look at the Common Vulnerability Scoring System (CVSS) and NVD's CVSSv2 calculator, which does a great job of demonstrating vulnerability assessment and scoring.


What policies maximize incident detection (and compromise detection)? What are the equivalent digital parallels to the practice of offering bonuses to employees challenging persons in a secured area without a visible badge?

The policy that improves incident detection is a policy to equip security staff with automated monitoring tools that save them from the tedious legwork of scouring log files and performing manual detection. By analogy: you don't improve physical security by asking your guard to walk faster, you give him CCTV monitors.


How can Insertion attack ever work and fool an IDS on a TCP connection? An IDS can accept a packet that an end-system rejects. An IDS that does this makes the mistake of believing that the end-system has accepted and processed the packet when it actually hasn't. An attacker can exploit this condition by sending packets to an end-system that it will reject, but that the IDS will think are valid. In doing this, the attacker is ``inserting'' data into the IDS --- no other system on the network cares about the bad packets. Secnet IDS Section 3.1

But I don't get it, if the IDS receives all of the packets and then passes them to the end system, and somehow the end system drops one of them (I guess with checksum or something?) then if its a TCP connection then wouldn't the end system wait until it has all of the packets before sending it to application layer and processing it?

I'm saying TCP because in the Insertion part of that website it gives an HTTP example of this attack, but if one of the packets are corrupted how can the end system process that HTTP request before all of the packets arrives?
even if we use URG and PSH flags on TCP, wouldn't the HTTP process wait until all of the packets arrive before translating the HTTP request and running it? I don't get how this can work? (Because if it translates the request before waiting for the packets to be in order, then the request might get corrupted and have no meaning)

In the website's example, it sends GET /cgi-bin/pleasedontdetecttthisforme? instead of GET /cgi-bin/phf? but I still don't understand how the end system translates and processes this request when one or some of the packets were corrupted? (based on TCP rules it should always wait before all the packets are OK and present before processing it)

The problem with some simple IDS/IPS devices is that they do not perform stream reassembly. They treat those two as different flows and throw the data away since they do not associate the two.

Luckily all modern IDS's perform stream reassembly. You can read about SNORT's implementation here: https://www.snort.org/faq/readme-stream5


Wildcard vs SAN certificates I have few questions regarding Wildcard vs SAN certificates.

Let’s say I’ve got a wildcard certificate for *.example.com, so the Wildcard certificate will cover all one level subdomains e.g. owa.example.com, contact.example.com etc. but it will not cover domains like test.owa.example.com.

It will not cover the main domain example.com, correct?
But if one goes to my site via www.example.com, it will work without any certificate warning, correct?

Wikipedia  says:

  The "naked" domain is valid when added separately as a Subject Alternative Name (SubjectAltName):[5]
  •   example.com >

So how to call then this type of certificate? Wildcard SAN certificate? Does that mean that a Wildcard certificate can be a SAN certificate at the same time?

Also, if a wildcard certificate applies to a given domain, example.com in this case, can I include different domains e.g. example.com, test.com, adam.com in a SAN certificate?

if one goes to my site via www.example.com , it will work without any certificate warning , correct?

Yes.

  how to call then this type of certificate ? Wildcard SAN certificate?

Whatever marketing department comes up with.

There is no fixed term "SAN certificate" -- it is a shorthand, possessive expression: a certificate with the SAN extension defined.

  if a wildcard certificate applies to a given domain, example.com in this case, can I include different domains e.g. example.com, test.com, adam.com in a SAN [ ]

Yes, you can.


How to verify the checksum of a downloaded file (pgp, sha, etc.)? Maybe I have been negligent towards the verification of software I download over the Internet, but I (or anybody I ever met) have never tried to verify the checksum of the contents I download. And because of this, I have no idea about how to verify the integrity of the downloaded item.

So how do I verify the checksum of a downloaded file?

Usually this would start on the owners side displaying the checksum for the file that you wish to download. Which would look something like the following:

md5: ba411cafee2f0f702572369da0b765e2

sha256: 2e17b6c1df874c4ef3a295889ba8dd7170bc5620606be9b7c14192c1b3c567aa

Now depending on what operating system you are using, once you have downloaded the required file you can compute a hash of it. First navigate to the directory of the file you downloaded, than:

Windows

CertUtil -hashfile filename MD5 / CertUtil -hashfile filename SHA256

Linux

md5sum filename / sha256sum filename

MacOS

md5 filename / shasum -a 256 filename

The issue that comes with checking a hash from a website is that it doesn't determine that the file is safe to download, just that what you have downloaded is the correct file, byte for byte. If the website has been compromised then you could be shown the hash for a different file, which in turn could be malicious.


Possible dangers of .doc files I just recieved some generic work related mail with word file attached that was requesting to Enable Editing in order to view its content. I'm not going to fall for it but it got me wondering. What could possibly happen to my PC if i enabled the editing there?

When you Enable Editing or Enable Content, you enable any macros embedded in the document to run.

An attacker can embed VBA (Visual Basic for Applications) macros in the document, which is really just a generic programming language.  With it they can access information about your computer, access resources like the network, and get malicious code like a backdoor or an remote access agent to run.  That code can use privilege escalation attacks to gain administrator access, if you weren't already running as an admin, and have full control over the computer.

So, good thing you didn't fall for it.

Note that newer versions of Word have bifurcated the format into .docx and .docm, where .docx files may not contain macros and .docm files may.  This is to make it easier to treat a file as 'safe' as opposed to having every file be a potential macro carrier.


Why are OSX users of my TLS-only site being asked to supply a client certificate? I purchased a Comodo SSL certificate (OV), and set up the Apache vhost config so that all traffic is forwarded to 443. Intermittently some users are being prompted to supply a client certificate; these users all seem to be OSX users, but it happens on both Safari and Chrome. Why does this happen? Why is it only OSX, and how can I stop this from happening?

I added the SSLVerifyClient line as shown as an experiment after this started happening (the default is none, but I wanted to try being explicit).

My vhost configuration follows at the end of the post.

Here are some of the screenshots from users (which, incidentally, is really a bad UX -- it surprises me that this shows up at all in OSX):

Here's my vhost config:

<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/
</VirtualHost>

<VirtualHost *:443>
    Header add Strict-Transport-Security "max-age=15768000"

    ServerAdmin example@yyy.com
    ServerName www.example.com
    ServerAlias example.com
    SetEnv APPLICATION_ENV production

    SSLEngine on
    SSLCertificateFile    /etc/apache2/ssl/example_com.crt
    SSLCertificateKeyFile /etc/apache2/ssl/example.key
    SSLCertificateChainFile /etc/apache2/ssl/example_com.ca-bundle
    SSLVerifyClient none

    BrowserMatch "MSIE [2-6]" \
            nokeepalive ssl-unclean-shutdown \
            downgrade-1.0 force-response-1.0
    # MSIE 7 and newer should be able to use keepalive
    BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

    AddHandler php5-fcgi .php
    Action php5-fcgi /php5-fcgi
    Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi
    FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi -socket /var/run/php5-fpm.sock -pass-header Authorization

    <FilesMatch "\.(cgi|shtml|phtml|php)$">
            SSLOptions +StdEnvVars
    </FilesMatch>
    <Directory /usr/lib/cgi-bin>
            SSLOptions +StdEnvVars
    </Directory>

    DocumentRoot /usr/local/zend/example/public
    <Directory /usr/local/zend/example/public>
            Options Indexes FollowSymLinks
            AllowOverride All
            allow from all
            php_admin_value open_basedir none
    </Directory>
</VirtualHost>

There is an .htaccess in the public dir:

RewriteEngine On
RewriteRule ^(.*)\.[\d]{10}\.(css|js)$ $1.$2 [L]

RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]

An SSL client will use a client certificate only if duly requested by the server. If both Chrome and Safari claim that the server requests a client certificate, then this probably means that the server indeed requests a client certificate. As was pointed out by @Ben, it is quite possible that the server requests certificates for everybody, but most non-OSX users don't have certificates at all and their browser silently answers to the server that they don't have any certificate.

To be sure that a certificate is indeed requested by the server, run Wireshark. You should be able to see the SSL handshake details, in particular the CertificateRequest handshake message from the server. You will also want to check that the server who requests a client certificate is indeed yours: verify that the Certificate message from the server contains the exact certificate that you configured on your server.

In any case, since the SSL handshake contains checksums which are computed over all exchanged handshake messages, a CertificateRequest message cannot be smuggled into your handshakes without breaking the procedure (client and/or server will complain loudly).

Unfortunately, the two suggested scenarios don't ultimately work:

If there is some load balancer misconfiguration which redirects some clients to another server, that other server should not have a certificate matching your site name. Client browsers should flash their scary warning popups. On the other hand, if the other server actually has a certificate with your site name in it, then this is an attack, and a very successful one; it would make little sense for the attacker to blow his own cover by stupidly asking for client certificates.
If the problem is a misconfiguration on your own server (e.g. a .htaccess file which overrides your SSLVerifyClient setting), then the problem should not be intermittent. For a given URL, it should always happen, or never.

My best guess (not a good guess, but the best I can offer) is that your site embeds some advertisements from a third-party ad provider, and some of these ads point to a misconfigured SSL-powered server. This would explain the "intermittent" part: you get the certificate popup on the random occasion where the ad provider points you at that specific misconfigured server. Trace analysis with Wireshark would reveal that, by the way: if you find a SSL handshake with a CertificateRequest message, then the corresponding Certificate message will contain the offending server's certificate, and the server's name (and you should also find it as part of the Server Name Indication extension in the ClientHello message). So go install Wireshark and see for yourself.

(On Windows, Microsoft's Network Monitor would work equally well.)


How can I authenticate the origin of an email? I just received an email that seemingly comes from Microsoft (invites@microsoft.com). Apart from asking Microsoft, is there a way to properly authenticate an email's origin with public key etc? (Especially from a company like MS or google?)

I just finished an Crypto intro course and am just curious about this in general.

Yes, but all the reliable methods are optional:

PGP signing (also depends on you already having a large PGP network or directly having accepted the real senders public key)
x509 signing (S/MIME) - which few people use, despite relatively painless setup on the signing side
DMARC - which probably isn't supported in your mail user agent but is gaining wide adoption in MTAs.
Sender Policy Framework - again is probably ignored by your user agent but commonly implemented in MTAs - Not as robust as the methods above which use cryptographic signatures.

A further issue with all of these technologies is that they are designed as means for computers to validate the identity of other computers rather than as a way of proving to human beings that an email is genuine.


How do vulnerability scanners detect when DEBUG is set to True on ASP.NET applications I know how to check this setting in code, and I know where to look in the web.config, but I can't seem to find information on how a vulnerability scanner like Qualys would detect this.

I've considered the following, but I have no way of knowing if my guesses are any good:

Is there an http header that is sent from the web server when Debug=true?
Is the scanner/software intentionally causing an error and detecting debug information reflected back to the client?
Is the software looking for long-running requests (since debug mode effectively lengthens response times before a timeout occurs)?

Setting the debug attribute will not result in a different error page.  Custom error pages are handled in the web.config in the configuration/system.web/customErrors node.  Some info.

One possibility is that the scanner is detecting this by looking at the Cache-Control http header.  This header will return private when you are in debug mode and public when you are not.  There is a good article that goes into some of this which can be found here.

A more likely possibility is that they are making a DEBUG request to the site and checking to see wether it is returning 200 or 403.  There is a good SO post on this here.

While having the debug attribute set to true can cause performance problems, it's not the only thing that can cause performance problems, so it seems like using this method would generate a lot of false positives.


Sharing a password for short term access to a shared resource I sometimes need to delegate access to a single-user/shared user website for short term administration purposes (eg. with a junior administrator for programmed maintenance).

I have requested multiple accounts, but apparently it is not an option.

My solution would be to change the password to a shared value before access, and change it back to the default password after.

I would record both passwords in the company password manager.

Do you see problems with this approach, and do you have a better suggestion?

Your approach is right; while you want to keep just one account and share it with others for a while, the best way is to change password before-share and then re-change after-share.


What medium for storing full-disk encryption keys is easy-to-use as well as easy-to-destroy? If I were to frequently work on sensitive data on a LUKS partition and wanted to be able to quickly destroy the keys to it, I figure it would make sense to—

encrypt that partition with a key file,
place the only copy of that key file on some sort of removable medium,
come up with a plan for destroying that removable medium quickly,
carry the removable medium (and equipment to destroy it) everywhere.

That way, if The Final Reckoning arrives, I can immediately destroy the removable medium, making the partition's data inaccessible.

The difficulty lies in choosing a medium which is both easy to use and easy to destroy.

USB sticks are convenient to use: just configure the boot partition to read the keyfile from there.  However, they are difficult to destroy quickly and reliably, necessitating destructive tools that are difficult to carry safely, and illegal to take on planes.
QR-codes printed on paper are inconvenient to use: I don't know of any LUKS implementation that allows key input by QR-scan.  However, they can be destroyed without equipment, by just eating the paper.
Memorising the key is both inconvenient to use (takes a while to rehearse, then have to type it in every time) and difficult to destroy (voluntary forgetting is difficult, though it is plausibly deniable).

How could I get both?

Your best bet would be a CD or DVD, as they are easy to use and easy to destroy (see below), with CDs being even easier to destroy because of the different data density. The main disadvantage is that they're bigger than a flash drive, and thus also harder to conceal, but I'm not sure if that's your problem. Anyway, if you don't fear X-rays, body scanners or a  proper patdown, you could try to conceal one under your clothes.

There are shredders which can be specifically used to destroy CDs and DVDs, and if you don't have access to them, you can always improvise using a garden scissor (or any kind of scissors/blade capable of cutting through plastic and such)  and a blender. I think you could mechanically destroy a CD in this way in under 5 minutes. You can also shred them using a microwave - which is probably quicker -, or even combine different techniques.

For more information, read this question on Superuser and its answers.

The other possibility would be a USB drive or a SD card. They are smaller and easier to conceal, and easy to use, but they're also harder to destroy via improvised, mechanical means.


What user information does Wikipedia retain when a page is viewed? People worry about privacy issues of Facebook and Google, but Wikipedia, being the nice and not-for-profit guys that they really are, does not receive much attention. However, if access logs are not properly taken care of, they could be mined and exploited by third parties.

Wikimedia is clearer about what happens when you edit a page, such as keeping IP logs. When it comes to simple access and visualization of a page, it's not so clear. Wikipedia privacy policy says that

  When a visitor requests or reads a page, or sends email to a Wikimedia server, no more information is collected than is typically collected by web sites. The Wikimedia Foundation may keep raw logs of such transactions, but these will not be published or used to track legitimate users.

The words 'typically' and 'may' are weasel and raise some questions. For example, what is logged? IP, browser version and OS are typical, is it also logged, as in the edits? For how long is it kept?

It's true that

  Wikimedia policy does not permit distribution of personally identifiable information under any circumstances.

But it made me wonder that since selected editors have privileged access to that information it may only take one human error or evil intent to leak it.

The 'simple English' version of the privacy policy page describes what information is logged on page view:
http://simple.wikipedia.org/wiki/Wikipedia:Privacy_policy#Private_logging

64.164.82.142 - - [21/Oct/2003:02:03:19 +0000]
"GET /wiki/draft_privacy_policy HTTP/1.1" 200 18084
"http://en.wikipedia.org/wiki/Wikimedia_projects:Village_pump"
"Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5"

This log is said to be sampled but they typically store IP, timestamp, referrer and browser. Some countries do not allow conservation of logs containing IP addresses for more than 6 months (like France). Wikipedia says that "These logs are used to produce the site statistics pages; the raw log data is not made public, and is normally discarded after about two weeks."

Log data may be examined by developers in the course of solving technical problems, in tracking down badly-behaved web spiders that overwhelm the site, or very rarely to correlate usernames and network addresses of edits in investigating abuse of the wiki.

Derived data from this log are not supposed to be released except in the following cases:

In response to a valid subpoena or other compulsory request from law enforcement
With permission of the affected user
To Jimbo Wales, his legal counsel, or his designee, when necessary for investigation of abuse complaints.
Where the information pertains to page views generated by a spider or bot and its dissemination is necessary to illustrate or resolve technical issues.
Where the user has been vandalising articles or persistently behaving in a disruptive way, data may be released to assist in the targeting of IP blocks, or to assist in the formulation of a complaint to relevant Internet Service Providers
Where it is reasonably necessary to protect the rights, property or safety of the Wikimedia Foundation, its users or the public.

So it is again pretty vague...

Note that Wikipedia does not store cookie (tos-dr) and does not host third-party trackers (conf. Ghostery)


Security Concerns with X11 Forwarding What are some of the security concerns and reasons either for or against allowing X11 Forwarding.  I have generally taken an approach of not allowing it under the blanket guise of security.  Recently, I had a user indicated that they thought that the security implications of resulting from allowing X11 Forwarded sessions were negligible.  I was curious to learn more about what the harm is in allowing X11 Forwarding and why one might want to allow it.

The implication of X11 forwarding is that it opens a channel from the server back to the client. In a simple SSH session, the client is more trusted than the server: anyone in control of the client can run commands on the server (assuming shell access), but the converse is not true. With X11 forwarding, the server is likely to gain shell access to the client.

In a text session, there is a limited channel from the server back to the client: the server determines the output that is displayed on the client, and can in particular try to exploit escape sequences in the terminal running on the client,

In an X11 session, the server can send X11 commands back to the client. X11 was not designed with security in mind, it was designed with the idea that all programs that you're displaying are run by you and hence trusted anyway. By default, SSH subjects commands from the server to restrictions through the X11 SECURITY extension. The SECURITY extension disables some obvious attacks such as keyboard grabs and key injection, but allows others like focus stealing.


How often do brute force attacks find the password or key in a much shorter amount of time than the theoretical max? For a 128-bit key, it would theoretically take many years and a percentage of the entire worlds power output to check every possible key, or for 256-bit it would take 3 sexdecillion years. But the brute force attack only continues to check while it has not found the key.

What are the chances that the key is the very last key for the brute force attack to check?

What are the chances that the key is one of the first few keys to be tested by the brute force attack? or even if it's one of the keys in the first 10% of all keys to be checked by the brute force attack? Just because there are a lot of zeros on all these numbers, couldn't the brute force attacker get lucky and guess the key?

Does the huge size of the search space (for 128-bit, 3.4*10^38) reduce that possibility to an acceptable risk level? People win the lottery all the time, despite there being a 1 in 10^6ish chance.

Has this ever been tested? Has anyone ever generated hundreds/thousands/n of keys and then tried to brute force them for a short time to see how often the key is found in minutes/days?

Edit: I am now curious about the distribution of keys, is it uniform? Also, can this reasoning be extended, say I do have thousands of similar security (all 128 aes) keys to crack, when I run a brute force attack to find them, a small amount of them should be found relatively quickly right? (or quickly compared to the theoretical max 10^100... years)

What are the chances that the key is the very last key for the brute force attack to check?

If there are N keys, the chance is 1/N. If you have n bits of entropy, that means the chance is 2-n.

  ...if it's one of the keys in the first 10% of all keys to be checked by the brute force attack?

Given that the key is random, the chance of a brute force search finding it within the first X% of tries is X%. So the chance of finding it among the first 10% is 10%. If a full search would take 10 years, the probability of the key being found within one year is 10%.

Forget about the crypto here, this is just statistics. If you have 1 000 cookies, and one is poisoned, how big is the probability that you die if you eat 10?

  Does the huge size of the search space (for 128-bit, 3.4*10^38) reduce that possibility to an acceptable risk level?

Yes. If the keyspace is large enough, the risk of an attacker getting lucky is neglible. A full search of the AES-128 keyspace would take about 100 times the age of the universe. If you had spend all the time since the big bang brute forcing a key, you would still only have a 1% chance of cracking it. And if you only give yourself 100 years, the odds drop to 1 in 1010.

  Has this ever been tested? Has anyone ever generated hundreds/thousands/n of keys and then tried to brute force them for a short time to see how often the key is found in minutes/days?

For small time periods, you  have just a big a chance of finding a match if you try to crack one key all of the time as if you divide the time over multiple keys. So again, if you spend 100 years trying billions of keys for a little while, the chance of you getting a hit is close to zero.


Can I use root account if every server only runs one service [Debian/Ubuntu Server] Usually people say directly using root account is a very bad idea. However, my current setting is like this: to achieve a higher level of isolation, all services have their own virtual machine instances.
In this scenario, is it okay to simply use root account on every virtual machine instance? The common argument is that separating root/non-privileged users reduce the attack vector--even if one service is compromised, other services on the same system can still be secure if they use their separate non-privileged accounts. But since there is only one service for each system, this argument seems invalid.
I am aware that there are some other arguments. For example, rm -rf, etc could be less dangerous  in non-privileged accounts. But I think this is not a huge concern since those services are not updated very frequently and the virtual machine instance will be backed up regularly.

I would agree that root can be used on your VMs much more relaxed due to the compensating controls that you specified however without knowing your setup and if this is a corporate or personal set.
My considerations as to why root on all is a bad idea:

As an attacker, automatic root account would allow me easier access to misuse the VM and put my own tools on.
If access to the server is automatic root, logs can easily be deleted/modified/read. This could include any bash history.

Virtual Machines are also commonly given a misconception around how secure they really are. For a good resource from another Infosec Stack Exchange comment just look here.
At the end of the day this is your environment and this is your risk acceptance. If the value of keeping them root out of ease is best for you I would say that is fair (judging by you being on this forum and knowledge of the dreaded rm -rf I would say you are already capable of weighing the risk adequately).
My summary would be:

If it was my home network, non-important, and weren't externally accessible outside my LAN, I would rely on my network logging and monitoring and throw access out the window.
If this was any other situation (running accessible services, corporate use, R&D, sensitive PII, etc.) I would DEFINITELY enable least protection privileges and check those SUID bits and GTFOBins.

Hope this helps.


Snapchat tracking over company WiFi. What can they see, save or open? I sent a snapchat to a coworker during company time. I was not on the work wifi, but now I believe they may have been. What will my employer be able to see from the snapchat that was sent and opened over the WiFi? I believe there is a certificate agreement in order to log in but I don't know for sure.

Snapchat used to use a famously weak crypto implementation with a global key stored in the source code to encrypt pictures at rest, so they are infamous when it comes to security.

But, luckily enough, all communication is over HTTPS. That means the owner of the network (your company) can not MitM the users (your friend) and read the content of their messages. They can, however, see who communicates with who. Since the Snapchat app communicates with the Snapchat servers, and not directly with the person the messages are adressed to, they could see that your friend used Snapchat, but not that she chatted with you or what she sent.

Some caveats that could undo this:

Maybe Snapchat messed up the TLS implementation, and don't check the certificates properly.
Maybe your company forced you (or in this case, your coworker since she was the one on the WiFi) to install a certificate in your trust store to allow them to inspect your HTTPS traffic.
If these are company phones we are talking about, they could have all sorts of monitoring on the phone in place.

If any of those points apply, your company could potentially see the whole communication - the photos, the recipients, everything.


Security weaknesses in using RSA encrypted MD5 hash of certificate content Suppose you have an Internet banking site based on a secure web server running the HTTPS protocol via port 443.

The server authenticates itself to clients through an X.509 certificate signed by a CA. The signature is constructed by using RSA encryption of the MD5 hash of the certificate content. The key used for the encryption is a 512-bit private key of the CA.

What is the most obvious weaknesses in such a "setup"? I thought the use of MD5 for integrity would be a weak point as MD5 has been broken. But since it's encrypted with RSA using a 512-bit private key, I guess the MD5 can't really be manipulated?

There are two big weaknesses in what you describe -- and one source of confusion.

The source of confusion is that you are talking about "encryption with the private key" which is a flawed analogy. Really, this is a digital signature. Historically, digital signatures with RSA were first explained as "encryption with the private key", but this proves only confusing because such an explanation conjures images of confidential data, which do not apply to this case. Moreover, it is wrong: standard-compliant RSA signatures (as per PKCS#1) are not "encryption with the private key".

In the situation you describe, the weakness that the examiner expects (I assume this is homework) is that MD5 is weak against collisions; this would allow an attacker to craft a pair of certificate contents, one with his name, the other with the name of the bank site, such that they both hash to the same value. He would then get a certificate for the first case (legitimately) and then use the resulting signature on the second certificate. See this page for a demonstration and a lot of explanations (read it !). The important conceptual point here is that the MD5 hash value can be predicted by the attacker since everything which enters MD5 is known -- thus, thinking about it in terms of "MD5 value was encrypted" triggers exactly the wrong ideas.

The other glaring weakness is that 512-bit RSA is weak. A 512-bit RSA key was broken back in 1999. Several other similarly-sized keys have been broken since; in one case (in 2012), this was done with open-source software and 75$ worth of rented cloud-based CPU.


Can programs see your windows account name given admin rights? The windows account name can be seen as one the folders in C:\Users. Assuming you changed your windows account name to something different to the folder, can programs see your new windows account name given admin rights?

Programs can get the current username using GetUserName() and the path of profile directory e.g. using GetUserProfileDirectoryA(). They use API calls instead of deducing something from directory names. And no administrative rights required for these.


how to disable detecting video capture I need to capture a video stream playing on a video player with my recording program. (windows 7)

But whenever I tried to run both of programs (video player and capture program) the video player stops with a message that there is a capture program running.

I think the video player can detect capture program running. I changed the name of the capture program but it doesn't work.

Is there any program that disable detection of capturing videos?
How can I capture the video stream?
Any idea would be welcome.

The terms of use of the video streaming service most probably explicitly mark the subverting of security measures as illegal.
Probably it's a large site if it has a detection mechanism like this.
If it is legal for you to copy, you could try to find it on a torrent network.


Are spam invites on Google calendar dangerous? I was recently "invited" to win a free phone on my Google calendar. At first I was concerned that my account was compromised, but i think anyone can send a calendar invite.

Is it safe for me to ignore these invites (and obviously never follow any links), or is there some action I need to take to secure my account?

it is not dangerous unless you open a link, or open any kind of attachments.  of course vulnerability in Google calendar is another issue. (like zero-day exploits that are out of your hands).
in general enable two step security on your account, install update asap, and you are ok.


Is there a drawback to exposing the reason for login failure if # of combinations is compensated with password complexity? When entering username and password credentials, it's considered more secure to provide a generic login failure for different failure reasons (unknown account, wrong password, etc.) (ref: http://shiro.apache.org/10-minute-tutorial.html - there might be a better one).

That obviously increases the number of combinations a (brute-force) attacker has to try, but is not as helpful to the user as possible and might even lead to severe frustration if he/she is by accident convinced that the username is correct.

Is there a drawback to exposing the specific login failure reason to the user/potential attacker and compensating the decrease in number of combinations to try with more complex passwords?

I believe your proposal of increasing password complexity successfully mitigates the increased risk of exposing username information, especially if you consider that most registration pages already allow you to enumerate usernames by trying to register existing ones (albeit typically behind a CAPTCHA).

However, even if there isn't any drawback from a security standpoint, if the choice is between:

Display generic (less helpful) login messages.
Display more helpful login messages in conjunction with increasing the minimum password length by (for example) at least 4 characters.

It's likely that with #2 the collective increase in annoyance for all users is greater than the amount saved.


How do indirect, session-specific resource tokens increase security? The OWASP web site recommends this:

Use per user or session indirect object references. This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. [italics mine]
Check access. Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object. [italics mine]

So if a user doesn't have access to the requested resource, how does obfuscating the direct object reference improve security?

Given the increased complexity that, say, an ASP.NET MVC site would accrue, is this worth the additional trouble for anything but banking sites?

I will explain this by giving an example:

Suggest you have a list of objects in your database named:

Pear
Apple
Orange

You have a query which fills up a hash table stored in your session which maps the fruits you are authorized to have to a number:

1 => Pear
2 => Apple

You do not have access  to Orange. You then have a function which allows you to add fruits to a basket, so you choose a number 1 or 2 (this is the indirect object reference). Orange is not accessible in this session as it's not present in the hashtable (there is no number 3). With direct object reference you would have a function which just uses Apple, Pear, Orange rather than a number. So you could abuse the function (if no access controls are used) to add the Orange to your basket as well.

I personally do not see issues with direct object reference IF adequate access controls are in place. These access controls should be tested extensively. There might be more critical applications than others where this might be required, but imagine applications where there are thousands of users with each 100 or 1.000 options unique to them. Storing all of these in a session could have a significant impact on performance (considering the server will need to store this information for each client on the webserver).

Now to answer your first question: simply because it won't be loaded into the session. As in my hashtable example you simply won't have orange available.


Why doesn't Outlook handle phishing URLs There are two MAJOR problems at my company (as in several others also I presume).

Users clicking on links in phishing emails.
Users opening (and running) malware-infected attachments.

Yes, I should block attachments and I do. Everything but PDF, excel, word and ppt which I simply can't unless we want to go out of business. Everything else is blocked on server level.

Yes, I know that the users should be educated. They are. But they still click links and open attachments. More education? Sure, but I will never reach 100%. Not even 75%. So what is the solution? We run both IDS and IPS with 24/7 monitoring via a SOC. All emails are monitored and all attachments run in a sandbox before being delivered to end users. URLs in emails are also checked (via third party solution against a cloud-based blacklist). And on top of this, all clients run a multi-layered endpoint antivirus. End users are STILL being infected since attachments contain new strains of malware or 0-days and URLs have not yet been blacklisted. I believe that certain easy solutions are overlooked in general regarding phishing. Do you agree? (See below.)

We use Outlook as an email client and the questions I ask myself every single day is why Outlook doesn't have better phishing protection. For example:

Why doesn't Outlook check if the link text contains a URL that is different from the <a href-URL>. Why should the user have to hoover every URL and make their own decision?
Why doesn't Outlook check if the FROM field differs from the envelope email header? The oldest trick in the phishing handbook. Why should I let the users try to notice this themselves?
Why can't I ask Outlook to scan all emails for certain "dangerous phishing words" like e.g. FedEx, Visa, Mastercard, password, bank account, reset password, confirm account etc etc. Yes, I know about DLP but now I am talking about a client-side solution for incoming emails.
Why on earth is it not possible to turn off ALL links in ALL emails in Outlook? As far as I know it is only possible for plain text emails. This will not make it 100% secure, but at least it will prevent people from clicking links without thinking (i.e. copy-pasting).
Why can't Outlook notify a user that the email they just received is from an unknown sender (i.e. not in their address book) and has an attachment? All in all, this is often highly suspicious.

The above is just very simple things that could be implemented within the email program on the client side and make life easier for end users and for sysadmins.

What is it that I am missing in this line of reasoning? It must be something since this is not implemented in any email software. Or is it? Any thoughts about this are greatly appreciated.

Wow, lots in that question to try and get through.

First, what might you be missing? I'd suggest two things from experience. Firstly, the client PC's should only run whitelisted applications, everything else should be blocked. This cancels out masses of malware.

Second, kill off access to all known advert servers, malware sources and command and control (C3) servers - at the Router/Firewall level. You can obtain lists to support this if you like but most people use a smart filtering server such as those from Sophos and others. I even have a script that does this for my home Ubiquiti router - brilliant. This kills off many malware risks and drive-by attacks from rogue adverts. It will also protect from some, at least, of those nasty links.

Next, the unwritten question: Why is Outlook rubbish and other clients not a lot better? This puzzles me as well. With all the advances in UX, information theory and our understanding of thought, you would think that we would have a vastly better core written communications system by now. All I can think of is that email and related comms technologies are seriously uncool to developers. So they get badly ignored.

Now the specifics:

Do you mean something like Intranet Home Page? I think that you might find that cropping up a fair bit in legitimate HTML formatted emails. As found in enterprises large and small everywhere.
Two issues here.

Firstly, your email server should do that, don't leave it to the client.

Secondly, there are cases where this is used (though whether legitimately is perhaps arguable). External systems sending email as a corporate email is the typical case. Some cloud based mailing lists used internally, scan to email systems sometimes. All of these are regularly seen spoofing from addresses. Not really good practice but still far too commonly used.
Because a) the words you list are valid words for many organisations and b) because this too should be done by the server not the client. Check out the open source Spamassassin for example.

This is not a simple task though and you have to try and be clever about combinations of words and other markers - this is a soft scoring thing not a definite identification - one persons junk is anothers legitimate email. Of course, the bad guys have access to the same tools and adapt accordingly.

DLP is about data leakage rather than spam/maware discovery. There are client side tools that do this and Outlook's own junk discovery process makes a ham-fisted attempt. You will need 3rd party tools though to do it properly.
Well this is certainly theoretically possible since that is what happens in Outlooks junk folder. No idea why this isn't an option for everywhere else though.

However, Outlook is meant to be an enterprise email tool and actually most enterprises rightly make use of HTML emails in order to avoid people constantly sending one-page Word documents (AKA "memos") to each other like in the 19th C. So again, there has to be a balance - not saying the balance is right, just pointing it out.
Once again, this is not the experience of many large enterprise users that are the mainstay of Outlook customers. I constantly get emails with attachments from people not in my immediate contact list.

It wouldn't be that hard to adjust your server-based spam-checking service though to include this as a rule.

Trust me though, I hear your cry of despair. I find that the higher up the organisation chain you get, the more likely someone is to fall foul of malware/phishing links too!

We've had good results though with a constant drip feed of reminders and warnings. Making sure you always do a fairly intrusive extra "virus scan" using an engineer at the desk (or remotely) also helps drive the message home even if you know one isn't really needed. ;)

It is also good to do a deal with your senior execs then do some internal phishing exercises - after warning everyone that you are going to. If you can catch someone senior out, try to see if they are brave enough to be used as an example. In any case, publish some results and repeat a few months later.


Non-repudiation in Exchange/Outlook without Digital Signatures Scenario:  Acme Corp. needs to collect evidence to support their side of a case in court.  Part of this evidence may include e-mail messages.  Certain employees who do not have administrative access to the e-mail server, but may have administrative access to their workstations, might have motive to alter this evidence.

Acme Corp. employees do not regularly make use of digital signatures in e-mail messages.

Acme Corp.'s e-mail is stored on an Exchange server which is regularly backed up, and employees download messages to Outlook on their workstations.  Folder size limits are in place on the server, so employees commonly archive messages to PST files locally on their workstations.

Question 1:  Given this scenario, how easy (on a scale of "Joe User" to "3l33t H4x0r") is it for suspect employees to alter un-signed e-mail evidence...

...in their Inbox?
...in their PST file?

Also, to what degree can this be done?  (Subject/Body/Sender/Recipients/Timestamps)

Question 2:  What kinds of tools might be used for modifying this un-signed e-mail evidence?  (Or, can it be done easily without specialized tools?)

Question 3:  How can Acme Corp. defend (or disprove) the validity of the un-signed e-mails?

Unless there is some special configuration I'm not familiar with:

Joe user. There is an Edit function, hiding right there under Other Actions (in Outlook 2007, at least...). Note you can only see this when you open it in full message view, and not in the preview pane (as I usually read it...). Note also that this is not available via OWA.
It may be possible to configure Exchange mailboxes to prevent that, but I'm not familiar with such a configuration (and no Exchange handy right now to check, sorry).
Re edit: It's a good question, what parts can be modified - subject/body/attachments are easy. Recipients and timestamps are not enabled by the Outlook UI, so at least JoeUser won't be piddling with those fields so easily... However, I'm sure it is possible to modify these, using other tools (or directly editing the file), but I'm not familiar with that. Also note the addition on the next point...
Outlook! :)
On the other hand, I have not researched deeply into the file formats or forensics - it is possible that outlook tracks changes to received messages, inside the file.
Also, note that I assume we're talking about received messages, not sent - it is trivial to fake any kind of claimed sent message, without actually sending it.
Besides the previous, note that if the email is not signed it is simple to send yourself a fake email message, that claims to be from any other user you want. At that point, of course, you can forge any part of the email you want. (This does depend, however, on your Exchange configuration - by default, it is possible to send near-arbitrary SMTP messages, though this can of course be changed, as it should be).
It cannot - in neither direction. Excepting, perhaps, a strict backup regime. 'Course, that would still be a steaming pile of work, to pull up the exact messages, and prove that it was the originally received message - this could probably only be done right if the backups were set correctly in the first place (i.e. backup the message as received, and not just what the user does in his inbox).
Also, I am not including here any form of behavioral forensics...

But there is a reason that digital signatures are required.


When changing a password, does it have to be completely different? When changing a password how important is it to have a significantly different one? For example is it bad to reverse the sequencing of the old password to make a new one or change a few numbers?

Why do you change a password?

because you were told to do so;
to defend against someone who knows your current password.

The issue with a small change is that given the current password, finding the new one is much easier.


Malware via power outlet This is perhaps a very dumb question, but as I have no knowledge nor experience of IT security I have no option but to ask here.

Is it possible to get malware onto your computer or smartphone by using the same power outlet (socket) as a malware-infected computer/smartphone etc?

For example if I use the power outlet at school that many other students use, or if I use the same power outlet at my friends house who always manage to get malware on his computer.

For malicious (really any) data to modify your computer, it is required that the data is interpreted at the target location. The only scenario I can see - and it is a far fetched one - is that some "smart socket" that may perform some action based on the quality or fluctuation on the network. Say that you, as an attacker, force the power fluctuation to perform the fluctuation-action, you can call this malicious activity. Far fetched.

Edit: As smart phones' charge connectors double as communication points, changing the roles is easy. If the phone charges from a computer, i.e. through USB, sending data instead is probably trivial. Of course, again, it's important that the phone interprets and acts on the incoming data.


How private is FB messenger video calling? Are video calls placed through FB messenger really private or safe? What is the probability that it could be sniffed or intercepted by hackers? Is Facebook recording the data or just meta data of the video calls? If so, for how long?

Like all other traffic going through facebook, it`s TLS encrypted, so sniffers would not be able to see the video.

I personally dont think that Facebook would store video calls because of limited resources, but always take these things with a pinch of precaution. If sharing sensitive data through video calls, try to look for an end-to-end encrypted service.

Storing metadata however, requries almost no space, so you can assume, they store at least a few things like who you called, for how long did you talk, timestamps, etc. It's just a few bytes of data, it takes nothing for them to store and information is power.


How should developers handle Form POST variables that conflict with route variables? In ASP.NET MVC, when I perform a HTTP post to /controller/action/UserID ...

and have a corresponding route /controller/action/{UserID}  ...

and if I do a Form POST, the POSTed data UserID overwrites anything that the route was originally says.  (at least it does in ASP.NET MVC4)

To me this says a few things:

Don't trust the URL... since POSTed data may hide what is really going on.
Anyone who can guess the route variable names in ASP.NET MVC, can put unexpected data into a controller
....?

Questions

Is this behavior consistent across other MVC frameworks (Rails etc)?
What are some ways to guard against this type of unexpected results?  Should every POST be cross checked with URL parameters?

Don't trust the URL... since POSTed data may hide what is really going on.

The URL should be treated as a client-side value and should not be trusted anyway. Anyone can easily alter the URL and could easily create a POST to any UserID.

Anyone who can guess the route variable names in ASP.NET MVC, can put unexpected data into a controller

This can happen anyway by parameter tampering. There are some useful pointers in this guide: http://msdn.microsoft.com/en-us/magazine/hh580736.aspx
Specifically

What Is It? Parameter tampering is an attack in which parameters are altered in order to change the application’s expected functionality. The parameters may be on a form, query string, cookies, database and so on. I’ll discuss attacks involving Web-based parameters.
How Is It Exploited? An attacker alters parameters to trick the application into performing an action it wasn’t intending. Suppose you save a user’s record by reading her user ID from the query string. Is this safe? No. An attacker can tamper with a URL in your application

In MVC this can happen via Model Binding:

Model binding is a great feature of Model-View-Controller (MVC) that helps with parameter checks as the properties on the Order object will automatically be populated and converted to their defined types based on the form information. ... Just be careful to limit what properties you allow to be populated and, again, don’t trust the page data for important items. ...
Note that I use the [Bind(Exclude)] attribute here to limit what MVC is binding into my Model in order to control what I do or don’t trust. This ensures the UserId won’t come from the form data and thus can’t be tampered with.

So you should also be careful that form parameters that don't exist in your view cannot be tampered and added by a malicious user. You would do this by adding the Exclude attribute:
public ActionResult Edit([Bind(Exclude="UserId")] Order order)

Is this behavior consistent across other MVC frameworks (Rails etc)?

Not sure, but I don't see it as a flaw as permission checks should be made on POSTs as well as your GETs. You application should not assume that a URL that has been POSTed to has permission to do this just because that of the false assertion that the URL with the form on must have been loaded first.

What are some ways to guard against this type of unexpected results? Should every POST be cross checked with URL parameters?

You code should just decide to take either the route variable or the POST variable (if it's provided to you from MVC as a method variable named UserID then why not use that, it doesn't matter if it was from POST data or the URL as long as you are consistent), and then make all logic decisions based on that. This includes the initial authorisation and also the processing and business logic - they should all use the same origin of the value to make sure actions are only carried out when authorised.


What *exactly* does it mean to detonate malware? Does it mean the same as to eliminate or disarm the threat or does it mean that the malware was activated/executed (whether it reached its target or detonated in a "controlled" manner, e.g., in a sandboxed environment)?

"Detonating malware" means that the marketing team behind the product you are reading about realized that they need to figure out new catchy terms to get your attention. After hours of creative meetings they came up with the (wrong) malware-explosive analogy and decided to use the word "detonation" to describe a random event of the overly simplified scenario sketched up on their whiteboard.


Assuring Client is Authorized to use JSON Web Token JSON Web Tokens ( JWT ) are server-signed objects that the issuing server uses to identify a user, track session data and authorize requests.

The fact that JWT are server-signed gives assurance that the token was produced by someone with access to the server's private or shared, symmetric key, but--what mechanism is in place to assure that the token is being sent to the server by an authorized user?

For example, let's say I have a server that issues a JWT out into the world. Regardless of whether or not I transmit that token over a secure connection, because data can be saved, decrypted and retransmitted by the client it seems safe to assume that once one client has a web token, everyone has that web token.

So, how am I to make sure on my server that tokens coming in over the wire actually are coming in from authorized parties?

In one sentence: you have to trust the client to use TLS and generally protect the token.

Like many token systems, JWT relies on the client to secure its token. Clients are already required to maintain credentials needed for authentication (eg: passwords) so this is not a radically different concept. Furthermore, JWTs typically have a much shorter expiration time than credentials so securing them is typically easier.

Below are some snippets from relevant specs.

The JWT RFC, which utilizes the JSON Web Signature RFC, requires the use of TLS:

  To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection.

JWTs are similar to the OAuth 2.0 concept of bearer tokens. The bearer token RFC states:

  Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key).  To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.

In section 5.2 it goes on to say that TLS must be used to ensurer security of the token in transit, both when obtaining the token and when using it:

  This requires that the communication interaction between the client and the authorization server, as well as the interaction between the client and the resource server, utilize confidentiality and integrity protection.


How safe is WSIT username authentication with symmetric key? I have an ajax-ws web service (exposed via glassfish) that uses username authentication with a symmetric key to encrypt and authenticate clients(link).

How secure is this mechanism? Is this enough to protect against MITM attacks and data sniffing?

Looking at the linked article this looks very similar to standard web authentication in that the server has a certicate, the client uses username/password auth. to authenticate and then a shared key is used to encrypt communications.

So on that basis the answer to your question is similar to what it would be for standard web auth.  Assuming that the client checks the validity of the servers certificate at runtime and that it posesses the means to check for things like certificate revocation it is reasonably likely to be protected against a MITM attack (unless the server certificate is compromised).

Data sniffing would be protected against the encryption of the data stream which appears from the docs to be done be symmetric encryption.


What are the accepted naming convention for the terms "public/private keys" and "certificates"? Is there an accepted naming convention for referring to PKI artifacts?

There seems to be a lot of confusion with the naming of artifacts.  For example, it seems that some people refer to:

public keys as certificates
public keys as public keys
certificates as public keys
certificates as certificates
private keys as key pairs
private keys as private keys
etc ..

Is there an authoritative reference or glossary that I can refer to?

The following are the "accepted naming", i.e. the terms that I would accept:

A public key is a mathematical object; it is half of the cryptographic key pair. For RSA, a public key is a pair of big integers (modulus and exponent), nothing more.

A private key is a mathematical object; it is the other half of the key pair. For RSA, a private key is a bunch of big integers (namely n, e, d, p, q, d mod p-1, d mod q-1 and q-1 mod p, where n and e are copies of the two corresponding values from the public key).

A key pair is a public key with the corresponding private key.

A certificate is a signed object which some elements and binds them together. That's what X.509 is about. Most certificates contain a public key (not the private key) and an identity (a "name") designating the owner of that key (i.e. the entity who controls the corresponding private key).

That being said, a lot of people use sloppy terminology and you can encounter a lot of jargon abuse. E.g.:

For usual algorithms (everybody uses RSA), the public key is easily recomputed from the private key (with RSA, the public key is a subset of the private key, so this recomputing is trivial). This leads some people to talk about "key pair" when they mean "private key" or vice versa.
Some people (in particular a substantial fraction of Microsoft's documentation) talk about "certificate" when they mean "the certificate and the private key corresponding to the public key which is in the certificate". PKCS#12 archive files (also known as "PFX") are usual containers for a certificate and its private key.
Many people don't grasp the difference between a certificate and a public key, and use the two terms in a seemingly random way.
Confusion is further enhanced when people being to talk about "public certificates" or "private certificates". Part of the problem is that games with key pairs and RSA-like algorithms are called public-key cryptography as opposed to "normal" cryptography, i.e. symmetric algorithms like AES. In symmetric cryptography, keys are secret and no key can be made public. So there is an expression: secret key. This term normally designates a key for a symmetric algorithm, which is a bunch of bits. But some people say "secret key" when they mean "private key", or vice versa.
I have also encountered "digital identity", "private identity", or "digital credentials", meaning a certificate, a private key, both, or something else. Depending on who does the talking.
There is also a notion of secret-key certificate which is either someone who considers "secret" and "private" to be interchangeable, or the specific case of a certificate used in some advanced "blind signature" schemes. This is research-level work, nothing standardized.

Bottom-line is that if you want to be reliably understood, then you must take care to define your terminology properly. Similarly, be prepared, when reading documents from other people, to encounter just about anything. Decent standards begin with a glossary which unambiguously defines the meaning of terms within the standard.


Password is visible in online sign up form I am about to sign up for an online school, which is an accredited statewide online school, and notice that the password they want me to enter is fully visible on the form. Should I be concern about their information security? Does a form like this indicates that the way the way the school protects students' data is not secure, such as storing password verbatim rather than something like one-way hash?
If such forms violate established data security practices, what document(s) should I refer to the school's IT people regarding that?

UPDATE:
The next screen reveals the password verbatim. I clipped away the user content, but the password was shown unencrypted, along with the student name and the user name:

Could you point me to the industry standards of password storage that I could forward them?

The main risks with making a password visible are:

The password can be seen by someone shoulder-surfing
The HTML element type may discern how the browser or browser extensions treat the data, possibly sending it to Google or another entity (e.g. for spell check).

There are some advantages to allowing the user to see what they entered, even temporarily. A user can check if they made any mistakes while typing it in. This is less effective when you already need to enter it twice though.

Does a form like this indicates that the way the way the school protects students' data is not secure, such as storing password verbatim rather than something like one-way hash?

From a technical standpoint, this form tells you nothing definitive about how the system works. Sure, you can make assumptions about their practices based on this, but they will just be assumptions.
In general, while there are some downsides to this, I don't think it is a huge issue.


Is using `file_get_contents` on a URL with concatenated parameters secure? I'm auditing some PHP code for a friend, and there are a couple of file_get_contents usages for GETting URLs where the user-supplied parameters are concatenated without any escaping, e.g.:

function getLocation($latitude='', $longitude='') {
    $geolocation = $latitude . ',' . $longitude;
    $request = 'http://maps.googleapis.com/maps/api/geocode/json?latlng=' . $geolocation . '&sensor=false';
    $file_contents = file_get_contents($request);
    $json_decode = json_decode($file_contents);
    // ...
}

Considering the prefix to the "filename" passed to file_get_contents is already fixed (ie, attacker can't use file://...), is there some way to abuse this function by passing malicious values to latitude and longitude arguments?

There are two advantages (from a security standpoint):

Starting with a hard-coded URL makes sure that nothing local would be loaded (although it would be hard to take advantage of it even still depending on what happens to the data after it is json decoded).
The user input is injected into the data parameters (i.e. after the question mark).

These limits a malicious user to only modifying the request parameters sent to the google geocoding API.  Looking at the available options,  it doesn't seem like there is much damage to be done there.

It is still best practice to filter user input.  The concept here is defense-in-depth. At the moment the risk seems to be very low, but what if a later code change further modifies the way the data is used, resulting in a vulnerability?  For instance, is that latitude and longitude from the user persisted into a database later down the line?  I presume not (or you have found it if so) since you are auditing and checking these less obvious issues.  However, my point is that this function hides the fact that it is working with unsanitized input, and therefore it later changes might inadvertently introduce a vulnerability.

So yes (as you know), best practice is to sanitize/validate user input before doing anything else.  However, there does not appear to be an immediate vulnerability as a result of that oversight here.

Of course, you can always just use the fact that this endpoint is directly connected to the google maps API to spam the page constantly, resulting in either a) a larger-than-expected bill or b) DOS part of their app because google rate limits their geoip lookups.


Become domain admin by controlling an OU in Active Directory? Some tools that draw links between objects in a Active Directory architecture, show that if we have an user who is administrator of an OU on which a domain administrator is also present, so he can take control of the domain.

Is that true?

How is it possible if so?

Should be straightforward enough;

As OU administrator, reset the domain administrator's password (as he
is in your OU)
Now you can log in as the domain administrator (you know the password
now)
Configure your account to be a domain administrator (as you're
currently authenticated as a domain admin).


Public folders security If using one standard user account (for daily task) and one administrator account, then while in standard you can download some virus or whatever and put that into public folder.
of course, assuming the malware is not detected.
Then when admin log's in to it's administrator account, there is a posibility that admin will infect whole system since that malware will be shown in his user profile.

Is there a way to disable public folders or something that can prevent sharing of files between users and administrators?

All Admin accounts need to be careful about what they run. The rule of thumb is to only run executables that have been vetted, and not to browse the Internet, if at all possible.

Disabling 'Public Folders' is not a solution, but merely a small measure towards the standard practice the Admin should be using.


How to minimize security risk when having to work with decrypted (plain text) passwords due to 3rd party API design I'm developing an application (C#) for Microsoft SharePoint platform that uses SQL Server's (2008 R2) Remote BLOB Storage (RBS) technology. To accomplish certain client-side tasks, I must obtain username/password pair from the database and pass it to a constructor that looks like this (MSDN):

public BlobStoreCredentials(string credentialName, byte[] credentialSecret)

Note that credentialSecret here expects a decrypted password; the password is encrypted internally after the constructor call.

Microsoft, for reasons unknown to me, by-design stores RBS passwords that I can feed to the above constructor symmetrically encrypted in the database, with encryption key stored inside the same database (to create/insert passwords, a Microsoft-provided stored procedure that accepts a plain-text password is used). From what little I know about security, this is no-go, correct?

To obtain a valid byte[] credentialSecret, I am apparently supposed to use a query that looks somewhat like this and returns username and decrypted password:

OPEN SYMMETRIC KEY skey
DECRYPTION BY CERTIFICATE cert;

SELECT [username], CONVERT(nvarchar, DecryptByKey(password))
FROM [credentials]
WHERE [id]=@userId;

I can then feed the decrypted password to the constructor (client-side) which encrypts it internally, uses it to perform some tasks and disposes the credentials at the end (see MSDN sample code above).

It seems to me that many things are very wrong with this design. Even if I decided to deploy a custom orthogonal database for storing one-way hashed passwords only, I would at one point need to "decrypt" them to plain-text to feed them to the constructor above.

My question is, are there ways to reasonably minimize security issues with this approach while accepting the premise of the question (i.e. I need to pass decrypted credentials to the constructor), or is this design inherently so insecure that it's beyond improvement? It's not just the technical aspect, but also about how to communicate situations like this to employer and just how to react (as a non-security guy) in general when dealing with a situation that seems to force me to use bad security design? The solution I presented obviously works, but it is - as far as I know - bad security-wise, not to mention it resembles a Rube Goldberg device.

(I apologize if this question is not specific enough for this site, but I don't know where else to evaluate my options.)

I have not used these technologies before but what I can tell you is if you decrypt the password in your SQL query then anyone on your network can sniff and get the passwords as plain text.

If I understand correctly, your C# will get the decrypted passwords?
If so I would recommend you have something such as in your C# application:

C# generate a random key (used for salt in your encryption) and sends salt to stored procedure in SQL.
The stored procedure will encrypt the password based on the salt (from the client)
C# will decrypt it based on salt key you provided

The attacker would be able to decrypt it, if he got the random salt and reverse engineer your C# (which is very easy due to been bytecodes) but least it isn't plain text or static encryption and much better than your plain-text.


Are SOCKS5 credentials safe during authentication on proxy server I've read several tutorials, but not totally sure.

If I'll set up my own SOCKS5 proxy server on VPS, configure it to use username and password. Will this credentials be safe while authentication on proxy via public wi-fi for example?

If no, how it works for paid proxy providers?

I know about VPN and SSH-tunneling. But I think they are too complicated for using on mobile devices and also leads to additional power consumption for keeping connections alive.

Neither traffic nor credentials are encrypted in the SOCKS5 protocol. From RFC 1929:

  This document describes a subnegotiation that provides authentication services to the SOCKS protocol. Since the request carries the password in cleartext, this subnegotiation is not recommended for environments where "sniffing" is possible and practical.


Session Hijacking through sessionId brute-forcing possible? cookies usually contain a sessionId to keep track of a logged user.

What would prevent a malicious user to forge millions of requests with random sessionIds and send them to a server, hoping to luckily end up with an existing session Id, and therefore stealing a random session ?

The only thing that comes to mind is the fact that the number of possibilities is quite large. However it is not infinite - I would imagine that a malicious botnet owner could easily make millions of tries in a short time.

How can I, as an application developer, prevent this ?

Thanks !

Session Hijacking through sessionId brute-forcing possible?

Probably not.

owasp says that a session identifier should be at least 128 bit long to prevent session bruteforcing. They give these example calculations:

  With a 64 bit session identifier, assume 32 bits of entropy. For a
  large web site, assume that the attacker can try 1,000 guesses per
  second and that there are 10,000 valid session identifiers at any
  given moment. Given these assumptions, the expected time for an
  attacker to successfully guess a valid session identifier is less than
  4 minutes.

  Now assume a 128 bit session identifier that provides 64 bits of
  entropy. With a very large web site, an attacker might try 10,000
  guesses per second with 100,000 valid session identifiers available to
  be guessed. Given these assumptions, the expected time for an attacker
  to successfully guess a valid session identifier is greater than 292
  years.

Even if we assume than an attacker can perform 10 million attempts per second, it would still take them 3 month to get a valid id in the last example given.

The session id of PHP for example seems to be 160 bits per default (I think, the documentation isn't so good), you can also set it yourself.

  How can I, as an application developer, prevent this ?

Apart from using a strong enough ID, you could also bind a session to an IP, or link it to a TLS session, that way, even if an attacker does obtain the session (via bruteforcing or in a different way), they cannot use it. And you could also block IPs that are using too many attempts with invalid session IDs.


Are the iPhone "connect the dots" passwords secure? A popular way to login to iPhones and other phones is to use a "connect the dots" password. For those unfamiliar, it looks something like this:

Is this kind of passwords secure from brute force attack (I'm excluding things like social engineering and just looking over their shoulder)? Note that this question is focusing only on the authentication, not from the iPhone itself being hacked

It's a simple way to keep honest people honest, but I wouldn't rely on it to stop a determined attacker.

It's not even secure against holding it up to a light and looking for smudges.

By looking at smudge patterns, you can figure out a few edges that are involved which reduces the search space to significantly better than brute force.

There is a pause built into it after a failed check though which offers some protection.


SSH_login not prompting meterprepter? So Basically I am trying to create a SSH session in metasploit. session opens successfully when I do sessions #, it prints [*] Starting interaction with 4... but when I do a dir, no result or no output.

How I do it?

use scanner/ssh/ssh_login
set USERNAME username
set PASSWORD password
set RHOSTS x.x.x.x
exploit

[*] Command shell session 4 opened (x.x.x.x:x -> x.x.x.x:x) at 2019-06-18 13:29:53 -0400
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

#sessions

Active sessions
===============

  Id  Name  Type           Information                                Connection
  --  ----  ----           -----------                                ----------
  4         shell windows  SSH x:x (x.x.x.x:22)  x.x.x.x -> x.x.x.x:22 (x.x.x.x)

Note: The IPs have been replaced with x

so now when I do:

msf5 auxiliary(scanner/ssh/ssh_login) > sessions 4
[*] Starting interaction with 4...

dir

Server OS:

Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

Client: Kali Linux x64

While you do not produce enough information about the target system to be certain, this behavior is often seen with connections that are not actually meterpreter sessions (i.e. when a nc connects to your listener, for example).

My best guess would be that a firewall or antivirus on the host suspended the process after the initial connection because the meterpreter payload got detected.


Prevent snapshots of VPS Pretend I have a server. Is there anyway to prevent (or make more difficult) the administrator from taking snapshots? Feel free to give me a software way, or suggest if I should change server types; dedicated server be better than a VPS, or KVM VPS be better than an OpenVZ VPS?

I know certain countries have laws, but I have trust issues. I am also aware that it is possible to dump the RAM and find the decryption key (in the event that the VPS is encrypted).

Thanks!

If you have a VPS the administrator of the underlying computer system can easily do snapshots and you cannot prevent this from inside the VPS. Similar you cannot prevent snapshots of a process by somebody having administrative access to the underlying operating system.

The only way to protect sensitive data inside a process/VM is to obfuscate them in order to make it harder to extract information from the snapshot. Better yet don't even have any sensitive data inside the process/VM, that is do your sensitive computations on a system where only you have control like done with Cloudflare Keyless SSL. Or use hardware where nobody except you have access, but even in this case somebody might have tampered with the hardware or it might backdoors inside by design.


How is the same origin policy causing my PoC to fail when I don't need to read return data? I'm performing an authorized vulnerability analysis on a custom web service and have discovered a CSRF vulnerability.

Due to there not being form tokens coupled with the service not checking for the origin header I believed I could forge requests via AJAX POSTs from an "infected" proof of concept page.

Due to the way the web server maintains state it requires a series of six sequential POSTs to complete my attack.  Here comes the problem:

My first PoC involved creating six simple html pages (each with one form) that I would load and submit one by one, in order, to validate my assumptions.  This worked fine so I converted these form actions to sequential AJAX POSTs.  My attack stopped working at this point.  I compared the actual HTTP requests for both content and order - all of the application layer data matches.

I became suspicious of the same origin policy for some reason despite NOT needing to read any return data so I started Chrome with the --disable-web-security option (to disable the policy), tried my attack again, and this time it succeeded.  It seems the same origin policy is somehow preventing my attack, but I have no idea why since I don't need to read any returned data.  What am I not understanding?  What have I not thought about?  Is there any way to accomplish what I want to do?

There is no reason that this should not work as long as third party cookies are enabled in your browser.

HTML form POSTs can be used, or in the case that the forms are a multi-stage process then this will be more useful to run as XHR requests as your attacking page can then control the requests and issue them in turn - just as your are doing.

Make sure that you are setting withCredentials on your AJAX requests.

In jQuery this is done like the following

$.ajax({
  type: "POST",
    url: 'http://www.example.com/Controller/Action',
    data: 'foo=bar',
    async: true,
    xhrFields: {
      withCredentials: true
   }
});

Other answers suggest that using withCredentials means that a CORS pre-flight request is sent to the resource instead of the intended GET or POST. This is not the case as long as the request is a "simple request". If your exploit worked with HTML forms then the correct AJAX equivalent would be a simple request, so check that all you code is correct.

  Cross-origin requests come in two flavors:

  simple requests
  "not-so-simple requests" (a term I just made up)

  Simple requests are requests that meet the following criteria:

  HTTP Method matches (case-sensitive) one of:

  HEAD
  GET
  POST

  HTTP Headers matches (case-insensitive):

  Accept
  Accept-Language
  Content-Language
  Last-Event-ID
  Content-Type, but only if the value is one of:

  application/x-www-form-urlencoded
  multipart/form-data
  text/plain

  Simple requests are characterized as such because they can already be made from a browser without using CORS.

This is actually mentioned in the CORS specification and indicates that CORS does not actually add security, it only enables cross-domain communication when both the client and server opt into the specification. If both parties do not opt in (such as in a CSRF attack where the victim site does not wish to be communicated to in this fashion), then the browser will act in a similar way to pre-CORS. i.e. cookies will be sent although the response will not be readable:

  resources conforming to this specification must always be prepared to expect simple cross-origin requests with credentials. Because of this, resources for which simple requests have significance other than retrieval must protect themselves from Cross-Site Request Forgery (CSRF) by requiring the inclusion of an unguessable token in the explicitly provided content of the request.

Back to your question:

  I compared the actual HTTP requests for both content and order - all of the application layer data matches.

I suggest that you use an intercepting proxy such as Burp or Fiddler2 to verify the requests. Checking the requests from inside the browser is not an accurate way of verifying this because the requests viewed in Chrome are subject to be interpreted from the Origin of the page they are issued from and if the Origin doesn't see the response due to the Same Origin Policy, then neither will you in dev tools. Chrome informs you of this via the “CAUTION: provisional headers are shown” message.

For example, the following is the same request as shown in Chrome dev tools and then in Burp. Notice how only the external tool shows the cookies.

I've tested this behaviour with Chrome 38, Firefox 32 and Internet Explorer 11 on Windows 7 x64, and it is consistent across browsers (however, make sure 3rd party cookies are enabled in settings) so this is further indication that this behaviour complies to current standards.

So my advice is to double check your code and requests using an intercepting proxy. Maybe post them on here for another pair of eyes to check as if it is working one way but not the other then there must be a mistake somewhere because the requests will not be the same.

Also, make sure that your code isn't exiting early due to the error returned because of Same Origin Policy violation.


Does EAP exist as an independent authentication protocol, or just as a framework? Does EAP exist as an authentication protocol itself, or will it only be found implemented as one of its methods (EAP-TLS, EAP-TTLS, etc)?

If EAP is only a framework, what additional detail do its methods provide that allows them to be utilised? Said differently, what stops EAP from being used as an authentication protocol rather than just a framework?

RFC 3748, the EAP specification, does two things: it specifies the EAP messaging protocol, and it provides threat modeling and security guidelines for authentication methods that run on top of it.  So in a sense, EAP is both a protocol and a standard.  EAP methods could be viewed as part of the EAP standard, but as merely running on top of the EAP protocol.

(RFC 3748 also defines three EAP methods -- MD5, OTP, and GTC -- by specifying how the pre-existing non-EAP versions of these authentication protocols are conducted over EAP.)

The EAP protocol is a transport protocol.  It provides a set of common features useful for authentication on top of an unspecified communications layer.  It could be viewed as the same sort of protocol as TCP, but designed specifically for authentication instead of bulk data transport.

What the EAP protocol provides:

A packet format for requests and responses.
Rules for transmitting requests and responses, and for matching responses to requests, with an eye towards eliminating meaningful opportunities for spoofing.
Rules for retransmitting dropped messages and for handling duplicate messages.
Rules for selecting an authentication method.
A facility for the authenticator to allow a back-end server to perform the actual authentication.

What the EAP protocol leaves up to the communications layer to provide:

Discovery and transport.  EAP assumes the supplicant and authenticator already know how to deliver messages to each other.
In-order message delivery.  The lower layer can drop or duplicate messages, but EAP assumes the messages will be delivered in order.

What the EAP protocol leaves up to the method to provide:

All of the details of how the supplicant and authenticator each decide that the other is trustworthy; including authentication, authorization, encryption, etc., subject to the security requirements in the standard.


Why does some popular software still use md5? Nowadays no one dares to defend md5 for any use, and of course they should not!

However, much popular software still uses md5 in applications such as password hashing (although it's not simple/plain md5 and probably uses advanced techniques such as salt + key stretching). I have heard, for example, that the Drupal CMS uses md5, and as far as I know many other programs still use md5. (I think Apache does, and perhaps quite a lot of forum software perhaps.)

Why is this? Is it tolerable?

It seems these are professional and popular programs with many years of development and informed developers.

Most remaining usages of MD5 are due to developers who just don't know better. If you are a frequent reader of this site, then you will soon learn that the "default" hash function to use is SHA-256; that's what cryptographers and standardization bodies recommend. But you will also notice an apparently endless stream of people who want to use MD5, or suggest MD5, or begin to ask themselves questions about MD5 and are in search of some guidance. This means that:

There is a considerably heavy Tradition of using MD5.
Information about how SHA-256 is much better than MD5, is not that widespread.
Most developers do development and are not skilled about security (and rarely care much about it). The "normal" development method (by which I mean the way most developers work) is:

Google up the current problem.
Copy&paste the first decent-looking solution that appears in some random blog or Q&A site.
Compile, run.
If it seems to work, blog about it. (optional)
Go to the next problem.

It is no mystery that 95% (at least) of Web sites and related applications are developed that way. But the Web is full of MD5; therefore, most applications will be full of MD5 as well -- and, because of point #4 above, the Web will be even fuller of MD5.

Note that in most cases, there is no urgency to replace MD5. MD5 is completely broken with regards to collisions, but it is still (almost) as good as new for preimages; also, it seems still fine for use in HMAC and derivatives (including PBKDF2). Collisions are not an issue in many case (and this includes password hashing; the problem of MD5 for password hashing is not collisions, but speed). So while MD5 is quite past its prime and shall not be used for new applications, a lot of existing usages of MD5 are still reasonably robust and do not warrant emergency update. Do not panic.


Nonprofit organizations asking me to email them a photo of my driver's license Recently I've had two nonprofit organizations ask me to email them a photo of my driver's license. No money is changing hands, and both of these are legitimate and well-known nonprofits.
Organization A wanted me to sign a document with a notary, but they also wanted me to email them a photo of my driver's license. This seemed weird to me, since it's the notary's job to check my ID. I told them that for security reasons I didn't want to email my driver's license, at which point they refused to go forward, which was OK with me.
Organization B is one that I'm going through a training process to volunteer with. This involves working with foster youth, and they have background checks, fingerprinting, and checks on my driving record. I assume they want my driver's license in order to verify my identity. (I would imagine that since they're getting my DMV records, they will be able to verify that I'm a licensed driver.) I explained my concerns about security and identity theft: that unencrypted email isn't secure, and that the image of my ID would potentially wind up on a bunch of different devices (server, desktop, phone), whose security could later be compromised. I suggested a couple of alternatives: snail-mailing them a copy, or doing a zoom call and holding the card up to the camera (while asking that they not take a screenshot).
Are my concerns reasonable? Are my suggested alternatives good ones?
I trust the intentions of the people making the requests, I just don't trust their knowledge of computer security and their ability to keep my information secure once it's on some random collection of devices, some of which may be people's phones, or devices managed by third parties.

Your concerns are reasonable if the server you/they are using isn't using an encrypted channel to communicate.
However, if your concerns are your private information, the security risk of an employee that takes a picture of your license and save it to his, hypothetically, backdoored computer isn't much different from using an unencrypted connection. You are just assuming that the employee is honest enough to accommodate your request to not take screenshots.


How does a 'rainbow table' hacker obtain password hashes in the first place? I don't understand this part of the Rainbow table attack.
In all my Google searches, it says that a hacker uses a rainbow table on password hashes.
But how does the hacker obtain the password hashes in the first place?
I have rephrased this question from a previous question which was closed:
How is Salting a password considered secure, when the hacker already has access to user password Database?
If the hacker already has the password hashes, can't he just use them to hack the system?

The news is full of examples of leaked databases (this is just the most recent results).
The How:
The vast majority of cases involve unsecured databases/backups (across pretty much all technologies: S3, mongodb, cassandra, mysql, etc....). These are usually due to configuration errors, bad defaults, or carelessness.
What data is leaked:
These generally provide at least read-only access to some or all of the data contained in the database, including usernames and hashed-and-salted passwords.
These dumps include a lot of private user records. Plaintext passwords (or using a simple hash such as md5) are even more problematic because that data can be used in credential stuffing attacks (by trying the same username/password combinations on different websites), potentially accessing even more data.
What to do with a password hash:
If an attacker has access to a hashed and salted password, they cannot just provide this to the server to authenticate. At login time, the server computes hash(salt + plaintext_password) and compares it with the value stored in the database. If the attacker attempts to use the hash, the server will just compute hash(salt + incoming_hash), resulting in a wrong value.
One scenario that could spell a lot of trouble is client-side-only password hashing. If the client computes and sends hash(salt + plaintext_password) into the login endpoint, then the stored hash can be used to login. This alone shows how dangerous that is to do. There are some algorithms that offload some of the work to the client (such as SCRAM) but they involve a more thorough client-server exchange to prevent exactly this scenario.
Password storage security is worried about attackers deriving the real password from the stored value. It is not concerned with other vectors of attack against the server.


What is the validity of the article which claimed that IE is more secure than Chrome? What is the validity of this article which claimed that IE is more secure than Chrome?

Don't believe 100% everything you read.

Personaly, everytime I see one product outpreformed others by huge margin I assume this is a case of PR and not of pure cold facts.

There are lots of events when, let's call them, hackers and enthusiasts are trying to bypass browsers defence. Call me sceptical, but to me they have much bigger value then any article on any site.
E.g. Pwn2Own


Website Visited by Unresolved Ip My Website is flooded with unknown visiters

Awstats says that my website getting thousands of hits in few seconds.
    I am using robots.txt and .htaccess, but the problem stays there. Please help me with this. Hosting service suspend my site because of this heavy traffic from unknown IP.

You simply can't protect your website from illegetimate requests like this. Consider moving your site behind a service which does packet scrubbing and verifies the legitimacy of the connection. One free service you could have a look at is CloudFlare.


Encoding output in JSON HTTP API I'm the author of a JSON REST API. This REST API is consumed by various clients, such as HTML/JS-clients, .NET clients (console applications) and Ruby clients. The output of the API is in JSON format, so it's formatted according to JSON rules and the neccessary special characters are escaped.

A security researcher reported to me that < and > are not escaped in the output, so if an attacker did a request such as HTTP POST https://my.api.example.com/blabla with the JSON body {Value:"<Hello>"} then my API will output something like {Response:"<Hello> is not a valid value"}.

The security researcher then explained that an attacker may be able to do a Reflected Cross-site scripting by using this.

My JSON API always returns a Content-Type: application/json header so my understanding is that modern clients will not try to interpret it as HTML.

< and > are valid characters in my API so I can't filter it out. One option would be to encode the characters it in the output, but HTML-encoding characters in a JSON API seems a bit strange to me. A third option would be to just remove the string from the output and instead say something like "The provided value was not valid", but that would reduce usability a bit.

Are there any good common practices how to handle this?

To some degree this is a matter of opinion, but I do not agree that there is a vulnerability here. If a client reflects HTML data from your JSON response without any sanitation, it is a vulnerability in that client and not in your API. Any webpage should treat API responses as untrusted data.

You are correct that HTML encoding the response is a bad idea. Why should the API make any assumptions about what is a proper encoding for the client? What if you want to use the API for a mobile app as well where the data will be displayed in a non HTML context? HTML encoding would just be bad design. It would be solving a problem for the client on the server side.

What I would do instead is to clearly document that the output may contain HTML special characters, and that the client should take appropriate action.

One thing, though: Make sure to respone with a no sniff header. Without it, mime sniffing browsers could interpret the response as HTML or JS, which would be a real vulnerability.