CA with lower key size than issued certificates

The strength of the key in the CA certificate is only relevant for the strength of the signature on the issued certificate. A weak enough CA key means that somebody could find the matching private key and would then be able to create arbitrary certificates which look like they were issued by the CA.

Thus a weak CA key does not affect the strength of the encryption or the strength of the key exchange but it weakens the authentication part of the TLS handshake. This means that the client more likely considers a server as the correct one even though it is an attacker which was able to create a fake certificate which essentially means a possible man in the middle attack.

Still, the 2048 bit RSA key in your example is still considered strong enough at the moment so it is not actually considered a practically relevant weakness currently.


Is it completely safe to store the unencrypted credentials within a variable in the ios device

Are you defending against an attacker with full access to the device? If so, a credential encrypted with a PIN code (which implies it consists of only 4 or 6 digits) is very easy to decrypt - a maximum of only 10,000 or 1,000,000 tries and you're there.

I would recommend verifying the PIN that the user entered against the server for authentication, and limiting (server-side) the amount of tries the user is allowed.


How do you get a secure bastion host if your IP address is constantly changing?

In the case described above... Instead of changing the security group everytime you go somewhere I would strongly advise using the AWS VPN. The VPN allows you to connect to a static IP directly. You use a VPN to connect to the AWS enviorment securely and can allow the security group to access the ip from the VPN.


Standardization

Don't expect any clients to be able to read those user IDs. User IDs following the schema provided are not part of the standard and will very likely not be implemented.

This is especially valid for providing mail addresses, which do have a formalized representation, including a mailto: prefix would break that.

Arbitrary Strings are Allowed

Anything beyond name, mail address and possibly a comment is not standardized, but the standard does not disallow anything, you can provide any string you want. Consider whether somebody else will be able to understand what you want information you want to provide, and whether giving the information is reasonable (thus, would anybody approve/certify the user ID?).

Maybe try to avoid matching the schema defined by RFC 2822, and do not put anything in angle brackets which does not fit an e-mail address you're able to receive mail on, as this is what implementations (and possible other users) would expect.

OpenPGP Notations

Another way to give (usage) restrictions would be using notations, but again, there is no defined way of using them, and I haven't heard of any implementation actually taking use of them.


Symmetric encryption involving load balancers - can't randomize key?

The standard mechanisms on making CBC more secure is to create a random IV (use in a cookie) and a message authentication code. You should use two static, randomly generated keys for this. Using a PBKDF is not a good idea: if an attacker can access the secret then the game is over, no matter what you do. PBKDF has been designed to eat CPU cycles, the opposite of what you are trying to when clustering for performance.

Unless you can differentiate between cluster machines (maybe make one more secure than the other) then adding more security will be tricky.


TLS 1.0 (and 1.1 in some configurations) are not considered to be secure and thus PCI compliant.  Currently PCI allows the creation of a mediation plan that will have everything resolved by June 30, 2016.   This is due for some browsers (IE) not having TLS 1.1 on by default.


Restrict network access for a single process with SELinux or AppArmor

AppArmor has the ability to block network connections from applications. I've never done it myself, but you should look at the AppArmor community page and the network rules page for details on how to do it.

From the looks of it, the deny network directive should allow you to block all network access for an application.


DLL hijacking requires an application that is vulnerable and the code in DLL gets the privileges the program calling it has. If the vulnerable program e.g. runs as SYSTEM or with administrator privileges (after the UAC prompt), the DLL gets the administrative privileges, but if the DLL is called from a process running as normal user, it has the same privileges the user has.
You are not supposed nor need to be able to change DLLs inside %SystemRoot%\System32\. You just need to be able to place your malicious DLL in a location that gets searched before the legitimate DLL, abusing the default Dynamic-Link Library Search Order with DLL Search Order Hijacking. For example if a desktop application is using a DLL from System32\, it may first search for the DLL with that name from its own directory. There are also other techniques like phantom DLL hijacking, DLL redirection, relative path DLL hijacking, but essentially the goal is always to trick a trusted application into loading an arbitrary DLL.
The DLL replacement you suggest is also listed on the same article from Wietze Beukema, but if replacing the DLL requires administrative privileges you don't yet have, that's not really privilege escalation, is it?
Of course there are some limitations. The program might check that the DLL is properly signed with a valid signature. The program might also crash, if the DLL doesn't fulfil its needs e.g. if there isn't a function it tries to call or it returns unexpected data. For these reasons all applications aren't vulnerable to DLL hijacking at all, and DLL hijacking might require the malicious DLL to more or less mimic the behaviour of the original legitimate DLL.


Getting an abnormal amount of firewall warnings on web server

If you want your service to be accessible to the public, then you cannot prevent the public from interacting with your service. Because of the nature of the web, you cannot prevent someone from accessing arbitrary resources on your site, even if they don't exist. So, you can't prevent the attacks.
There are techniques to detect when someone is trying to access things that do not exist (like /wp-admin.php) or from certain sources (like aabbccdd.xss.ht) and to block that IP from further interaction. But that tends to be more trouble than it's worth, and it will never be complete.
The better approach is to make sure your site can survive these random probes of your site, detect when things go wrong, and be able to respond quickly and effectively when they do. Because you want to run this server by yourself, then all that fall to you. And that's why most people host their sites with a service that can do that for them.


Recover a bitlocker encrypted hard drive

The bitlocker key is stored on the physical computer TPM (Possibly password protected, if you're in user authentication mode). So without the computer, you will have to manually provide the key (48-digit recovery password).

This recovery key should be available to the Active Directory Administrator (See tech support page) if they chose to do so, which for business continuity I hope they did.

While you have the recovery key, you can access the disk from any computer on which you can plug it on.


What is the use case of request signing in this mobile app?

Shouldn't the AccessKeyID and SecretKey be kept secret?

According to this:
Yes, they should be kept secret.

With this, a Man-In-The-Middle could sign all altered requests, so I
wonder what the actual use case of request signing is, in this
instance?

According to this
AWS access key ID is a form of unique user/account identifier
And
AWS secret key is like private key
So the signing is a way to authenticate\identify a user

Why would they sign the requests in the first place in their mobile
app? What is the use case of signing the requests, when the 'secrets'
for creating a signature are distributed via the same connection in
clear (except TLS)?

The reason why they designed it like this we would never know, but sending such a sensitive information in cleartext is not a good idea. However, according to this
The request is not signed with the secret itself, but with a signing key which is generated using the secret. It also uses HMAC-SHA256 for signing.

Thus, The AWS latest authentication mechanism simply will not accept secret key. It authenticate API requests based on the aforementioned way.


Is it possible to sniff traffic of a remote network? (With admin access to router)

If you can login remotely, then there will be very little that you cannot do.  Once you have a root shell, you can easily run tcpdump.  You can read the local databases that supply encryption keys elsewhere.  If within that shell, you are missing commands; you can write, or simply go find the commands you want.  If you do manage to get in, there is probably a lot of bandwidth; and you might go unnoticed for a while as long as things continue to work.

http://www.tomshardware.com/answers/id-2199813/blocking-backdoor-fios-router.html

However, most people will let the ISP setup the router that connects to the ISP; and that's not going to have the default password and let the world in.  Verizon uses an enormous UUID for the encryption key (written on a sticker on the modem), etc.  There will be misconfigured stuff out there, but it's not like it used to be (with end users going to Best Buy and (mis)configuring it himself).


Is there any way to protect a client-side game from a hacked client?

No, you can't protect your game from cheats if rolls are made from the client.

The main point of failure of your protocols is here

  The client reports to the server the (time stamp, outcome) pairs for
  each slot machine, and the server can verify that the outcomes are
  correct given the time stamp.

And you demonstrate its vulnerability below

  But this protocol is still not secure; it may not be tractable for the
  client to invert the mapping from time stamp to jackpot, but it can
  try many possible time stamps and report to the server the N most
  favorable outcomes.

Nothing prevent the client from reporting a false timestamp.
Moreover, even if there were a way to force the client to report every rolls correctly, in your particular case of a slot machine, the fact that the client might be able to guess its next rolls would be a critical vulnerability.


There is no real qualitative difference between a VPN and a proxy -- the difference is mostly quantitative. An HTTP proxy is a proxy for the HTTP protocol; a VPN is a proxy for TCP/IP and everything that can be conveyed within TCP/IP, including (but not only) HTTP. From an anonymity point of view, the proxy or VPN transfers the traffic that goes through it, and "sees" the source IP address and the data contents. If the data is encrypted (SSL...), the proxy or VPN can still see who talks to who, and the size of the exchanges.

Tor can be conceptually viewed as a randomly selected chain of proxies, with nested layers of encryption so that each proxy sees as little as possible. Adding an extra proxy does not really change the game. Arguably, using a Tor chain with one extra node would be better for anonymity, because, contrary to your manual proxy configuration, that extra node will be randomly selected and an extra nested layer of encryption will be applied.


In the normal TLS handshake procedure, the client sents a symmetric key to the server

No. What you describe kind of resembles  RSA key exchange, where the premaster secret is set by the client and sent encrypted to the server. They symmetric key and other keys are the derived from this. But RSA key exchange is considered obsolete and with Diffie-Hellman key exchange both parties compute a key together.
There is absolutely no difference in key exchange when client certificates are involved, no matter if RSA of DH key exchanged is used.


Why should I offer HTTP in addition to HTTPS?

For usability reasons you need to offer a redirect to HTTPS from all HTTP URL:s. Otherwise first time visitors who simply enter example.com/some/page into the URL bar of the browser will be greeted by a connection error.

Serving the redirect does not make you more vulnerable. Users who don't have your HSTS entry in their browsers will make a HTTP request anyway. Whether or not there is a real service or not on HTTP is irrelevant to a man in the middle.

So you need to run a HTTP server, but it doesn't need to respond with anything but the redirects.


Kali contains built in password word lists. They are compressed and can be found at:

/usr/share/wordlists/

I'm unaware of username lists, since usernames are usually pretty dependent on the format the service uses, and are typically fairly unique.

You can put together a simple non-exhaustive word lists for the users yourself containing obvious potential names such as:

admin
local
root
user
remote

Since you're using this to attack your own system though, you should already know what the username is, so you can just list that.

A brief reminder that you shouldn't use a tool like this to attack a system you don't have explicit permission to access. That would be a crime.


Bruteforce all IP addresses on network with Hydra

Did you try listing the options for Hydra with hydra -h or man hydra?

  -M FILE list of servers to be attacked in parallel, one entry per line

(No, you didn't.)


This answer is based on my personal experience building and participating in a number of darknets. I haven't interacted with them in a security perspective, but I have been involved heavily in one (Anonet) and helped found another (Underlink, which is now mostly defunct).

The most important thing to know about a darknet is the definition. My definition of a darknet is a private network with internet-like routing between peers, often on the infrastructure of the actual internet. This is not an all-encompassing definition, this is just the one I am most familiar with.

In practice, what you need to start a darknet are direct connections between machines. These machines will be peers. You can plug an ethernet cable from one computer to another (but usually the machines are hundreds of miles away), or you can setup point-to-point virtual tunnels (I have used quicktun, sigmavpn, and openvpn in the past).

Now that you have two machines directly connected, they need to do some kind of routing. The clients on your darknet are going to want to send packets to arbitrary IP addresses and expect them to get them. This is where your routing comes in. The darknets I have participated in typically use BGP routing. Each server interested in participating in routing typically gets its own ASN (e.g. AS3090). When two machines peer, there is now a connection between the two machines, and the BGP routing daemons you run will be configured to advertise it.

A sample network map will look like this (this is an old visual map of the actual BGP setup on Anonet6):

Each bubble represents a machine doing routing on Anonet. Typically each machine here would get a /24 (the above map is of ano6, but I'll use IPv4 terminology because it's the same idea), and be free to assign addresses inside that however it wanted; that machine would handle final routing for them.

So let's say that AS3090 (lex, in the middle) is a dedicated machine in some datacenter. All of my computers, though, connect to that server using some standard VPN software (OpenVPN, in this case), and are given addresses on AS3090's /24. If one of my machines connected to AS3090 wants to send a packet to a machine in AS31416 (far right of the map), it has a few simple options:

AS3090 (lex) -> AS1112 (UFO)     -> AS31416 (JCS)
AS3090 (lex) -> AS404 (chris)    -> AS31415 (JCS) -> AS31416 (JCS)
AS3090 (lex) -> AS404 (chris)    -> AS405 (chris) -> AS31416 (JCS)
AS3090 (lex) -> AS2323 (achedaz) -> AS1112 (UFO)  -> AS31416 (JCS)

(this is just a subset of possible paths)

This is all part of the BGP routing framework (fwiw, I used bird and bird6 to handle BGP routing advertisements, but there are many other programs that will do this; it's not necessary that peers use the same software, either).

The first path in my list is the shortest (in number of hops, not necessarily in terms of latency, since each hop could be, and often is, located on a different continent), so the packets will take that path there. The response packets may well take a different path back, but that's not important; as long as they get to the origin server, they can still talk.

The beauty of this setup is that it functions just like the real internet (in fact, core parts of the internet use BGP routing just like this). If AS3090 (lex) loses its connection with AS1112 (UFO), then the packets will automatically choose a different path to AS31416. It's redundant in this way.

This also makes darknets very good for anonymity. If I am AS12345 (dBZ, top middle), the only person on the entire network who knows my true IP (in the case of virtual tunnels over the internet; otherwise, this applies with direct connections or so) is my only peer, AS1 (r101). The rest only see my internal IP inside AS12345's subnet. For authorities, or anybody else, to find out AS12345's location/IP, they have to follow the chain of peers and break each one to find out who they're connecting with. This can be extremely expensive on large darknets, since peers often cross borders (in Anonet, we actually planned out to cross borders for additional anonymity).

This stuff is pretty easy once you understand it. The hard part in growing a network like this is that it's decentralized. Anonet split in half multiple times during its life. The peering between AS3090 (lex) and AS757 (Vutral) could break at any minute, and those two halves of Anonet would completely cease to be connected. But the people in each half would still be able to talk to eachother. You can cut the darknet in half and it still survives.

But typing in a friend's IP address to access their services (websites, file sharing, whatever) isn't fun. You want DNS, right? Well, that requires some central authority to make sure nobody is infringing on eachothers' claims. On Anonet, the way we "solved" that was with something called "resdb": a git repo containing a set of claims. Anybody could make claims and commit changes. The key was to get others to accept your changes into their copy of the git repo. This meant that different people had different versions of the repo, so for some people a domain doesn't exist, for others it does, and for others it might exist but point somewhere completely different. (resdb contained a set of files and scripts to generate zone files for BIND and similar so that anyone could run their own DNS server for the ano. TLD).

But you don't just need DNS reservations to be unique. IP allocations should be unique, too. Wouldn't we all like to be 172.160.0.0/24? If multiple people are using that, we get conflicts, which means that those go in resdb as well and you need to convince people to accept your claims. You also need to handle AS number reservations and a dozen other things that ICANN handles on the internet. It turns into a big mess and it's very hard to scale since there is no central authority which has the final say on reservations.

I hope this gave you a bit of an idea of what a darknet is. Again, this is not a full definition, it's just based on my experiences, and a lot of it isn't really relevant to your goal. I know, for example, that some people have attempted to create darknets by using consumer routers flashed with DD-WRT (to connect geographically close peers together) rather than using the existing infrastructure on the internet.

If you have any questions, please feel free to ask for clarification. I'm no expert, but I have played around with this stuff quite a bit just out of pure interest.

You can read more about Anonet here (some of the information is outdated, though).


What's the limiting resource that makes DDoS attacks possible?

Distributed Denial of Service is a type of DoS attack where multiple compromised systems target the resources of a single system to bring it offline.
The resources can be any of those you stated and they mostly fall into one of these categories:

Traffic attacks: Traffic flooding attacks send a huge volume of TCP, UDP and ICPM packets to the target. Legitimate requests get lost and these attacks may be accompanied by malware exploitation.

Bandwidth attacks: This DDos attack overloads the target with massive amounts of junk data. This results in a loss of network bandwidth and equipment resources and can lead to a complete denial of service.

Application attacks: Application-layer data messages can deplete resources in the application layer, leaving the target's system services unavailable.


The home directory encryption - at least the one in ubuntu - works for any folder. It does not matter if that folder exists on the local hard disk or is mounted using NFS. It even works in combination with the Ubuntu One cloud storage.

Just mount the directory first and then configure the encryption.


Why use a password manager to protect browser logons when e-mail client is neglected?

Many email clients protect the password in similar ways to a password manager (and some do not). No flaw in your logic, although once you get malware designed to steal password manager passwords, all bets are off anyway.

That's once reason why 2FA is so important. By setting up 2FA, even if malware gets your email password, they cannot use it apart from your system. They would need to control your email client in order to use the "password reset" functionality you mention. Is it possible for attackers to do this, yes, but the level of complexity is much higher than simply grabbing a password from memory/configs.


How could one determine if a web page is vulnerable?

The short answer is that I don't believe you can. One input field on one page may be far more important than 100 on another for example. The issue is that you cannot assess risk without access to more information. Risk is calculated by the ease and likelihood of a vulnerability being exploited multiplied by the damage that would be inflicted by its exploitation. You can't know this, or accurately guess this, without knowing more which might be internal code/architecture review or full testing.

That's why the saying we hear very often is so important "the attacker has to be lucky only once, you (the owner) have to be luck all the time" - so there may be one very small and innocent looking issue that once exploited gives the keys to the castle to the attacker.

It's also why all of the promoted pen tests/audit processes never include the advice "have a quick look and guess at what might be vulnerable and try that first"...

I'd advise against setting focus by guessing, you won't be 'lucky' much of the time


Packet filtering firewall - (Network Layer)

It allows any traffic targeted at the IP address 192.168.1.0 and any port numbered 1023 or higher through the firewall.


What kind of attack methods are you looking for?
I remember it has a memory leak in the DTLS-SRTP extension parsing code. Which makes OpenSSL vulnerable to DoS attacks (for more read CVE-2014-3513).

But I suggest reading RFC 5764 and see if that answers any of your questions.

Can also recommend "Prateek Gupta, Vitaly Shmatikov (2006) Security Analysis of Voice-over-IP Protocols"


What can I do with the removed Masterkey?

The idea behind an offline OpenPGP primary (master) key is that an attacker getting access to your computer will not be able to perform key management operations (creating/revoking new user IDs and subkeys, revoking your key, certifying other's keys). Furthermore, the primary key is the target of certifications between keys -- if you lose it (have to revoke it), you lose all connections in the web of trust. The primary private key is the most important entity in OpenPGP, and should protected accordingly. By removing the primary private key, you reduce the key's exposition to possible attacks, as it during the time the attacker has access to the computer.

Some people go even further and put the primary private key on a separate, dedicated machine not connected to any network, which further prevents attacks to this air-gapped computer.

  If I just remove the secret-masterkey and my PC gets stolen or something, then what can I actually do with only the secret-masterkey? I think I can revoke the subkeys, but can I create a new public-key and public-subkeys with the secret-key?

There is no reason of not putting a public key next to the private key. In fact, the OpenPGP standard does not even consider private keys without the public keys stored together (OpenPGP smart cards are an exception here). Also make sure to have a backup of the private key, of course (which should be kept separately, but with the same security level as the private key itself)!

  Or: is the idea doing a backup of the ~/.gnupg folder and removing the secret masterkey from the PC afterwards? So in case the PC gets stolen I still have all the keys for revocation?

This seems like the most reasonable way to go, but keep the backup safe. If the PC gets stolen/compromised/..., you can still revoke the primary key itself, or only rotate the subkeys (which is much easier to handle in terms of key management).

I for myself created the primary key on my old laptop, which is also used to create the subkeys and has all of them. This old laptop has the secret key imported and ready-to-use in the GnuPG keyring, but is not used for any other work but key management and certifications. For the daily-use machines, I export the respective secret subkeys individually as required.

A revocation key is readily available at several places, among them my daily-use laptop. The worst thing that might happen is the key gets revoked, but no further damage can be performed while I have additional protection against loss of the primary private key without being able to revoke it on the key servers.


preventing cross iframe key logging in javascript

Their best best is to turn on the X-Frame-Options header, as you mentioned.

While pointing this out won't help your cause, the reality is that if they haven't had that header on then they have been vulnerable to various iframe-related attacks this entire time anyway.  You trying to load their site in an iframe doesn't make them anymore vulnerable - it just takes makes them aware of a threat that they have already been vulnerable to anyway.  All that to say, them attempting to limit what you are doing probably doesn't make them more secure, because even though you are announcing your intent, attackers don't.

As a more general answer, due to the same origin policy, your site would not be able to listen to any keystrokes inside the iframe anyway (see this question for a starting point).  As a result their immediate concerns are actually unfounded.  With iframes you do have to be concerned about clickjacking, which is solved via the X-Frame-Options header.

However, that really isn't relevant here either.  To boil it down, you are trying to implement a solution where users login to your site and then access a third-party site through your system.  In essence, this is a variation on SSO.  Understanding that, and looking at things from their perspective, your original proposal (server-to-server authentication) is really the ideal solution.  The advantage for them is that they can easily log that a particular user session came from you.  As a result, if anything "unusual" happens during that session, they can potentially (and accurately) hold you responsible for anything bad that might happen.  Of course it may be that they simply (for whatever reason) do not want to participate in whatever it is that you are trying to accomplish.  Obviously, they have the right to make that decision if they feel it is best for their business.


What is the new certificate?

This depends on your AV manufacturer. It should be a wholly new generated certificate that is signed (or self-signed) upon installation, which is then put in your trusted root store. This way, the certificate is decoupled from the security vendor, and the private key is... well... private and unique to your computer. However, that may or may not happen. The AV vendor could use a single certificate that they generated and included with the installer. In the latter case, if the the security vendor loses control of the cert or the signing keys, it leaves the consumers vulnerable.

  What are the new attack vectors

Attack vectors include:

Bad actors replacing the certificate with their own, and sniffing traffic.
Security vendor doing something stupid with the certificate like including the private key so that attackers can mint their own certificates from that key and spy on your traffic.
Alter, change, and inject content on pages you visit.
Security vendor using weak security on the certificates, which is easy for bad actors to break and thus mint their own to take advantage of the cert installed on your machine.

There numerous other examples of failures resulting from bad implementations, which highlight the intricacies and complexities of trying to do this correctly. In my opinion, there is no need for a security vendor to do this. Vendors claim it will protect you from the dangers of the web, but this supposed increase in security (modest at best) opens you up to the weakest link in the vendor's entire chain. (More humans, more problems.)


There is also Untroubled.org,
They tend to publish montly spam as well.

http://untroubled.org/spam/


One explanation: Compressed data is harder to parse in real-time. If the product is performing some sort of content filtering on the live HTTP streams it is easier to deal with non-compressed streams. It may be scanning for malware, or blocking unapproved content (some of those products are enterprise oriented).

If the firewall is trying to parse the stream, it is advantageous to not have to deal with compressed streams. That requires buffering and decompressing the data after enough of it has been assembled, as well as a little CPU overhead in having to decode the compressed stream a total of twice. (Also, it's simply more effort.)


Does being multi-lingual (in the 'natural language' sense) ever come in handy at all in information or network security?

Code is written in English-based languages, and coders from any country generally know enough English not to need their native language even in comments.

The most accurate way of identifying a writer's country of origin in such a scenario is based on counting the frequency of various types of mistakes they make in English. This calls for scientific knowledge, not basic communication skills. A level of language not passable for native also won't help you much in infiltrating any group.

China and Russia are the go-to scapegoats for wrongdoings both in the cyber world and outside it, so it's likely that some attacks are misattributed to them by intent or by default. Throw a random hanzi or a cyrillic word from a dictionary in a comment and you've created a false lead to nowhere.

All in all, while learning foreign languages is certainly good for many reasons, it's hard to see how it would be more useful in IT security than elsewhere. If anything, this is one of the fields that put the most pressure on non-native speakers to learn English.


Is it that easy to crack a Windows SAM file?

With physically access its not very hard to crack or "erase" a windows machine password even if it has a bios password.

In windows XP in a most case if not fixed, you can login as a default admin in Safe Mode.

Ophcrack works by using LM hashes through rainbow tables. The program includes the ability to import the hashes from a variety of formats, including dumping directly from the SAM files of Windows.


Is use of HttpServletRequest.getQueryString() for a response header vulnerable to response splitting?

The general pattern of using data that comes from the user without sanitizing it is a source of vulnerabilities. Typical things like XSS and SQLi. In this case you are taking the input from the user and directly making it a header. This could lead to response splitting, header injection, and maybe another problem or two (eg: CSRF may be possible if you can inject Javascript). But you state that:

  my container is nice enough to strip the newlines from the header value

so this is preventing actual exploit.

I suspect that even if you were to filter the input such as:

path += "?" + sanitize(qs);

for an appropriate sanitize function (say from OWASP's AntiSamy project) that your static analyzer will continue to give you this finding. So, in the end, you're going to be marking this finding as a false positive (Not an issue if you're using Fortify). The only question is whether you should include a code change before marking the finding as a false positive.

My take is that if the API explicitly says that it is responsible for secure handling of newlines and other special characters, then no action is needed on your part. When I look at the Javadoc for HttpServletResponse.setHeader, I see no mention of how special characters will be handled. So, unless the spec explicitly states a secure handling of this (I don't think it does but I didn't look this up in the Servlet spec), I would recommend sanitizing the input and rerunning the static scanner. If, as I expect, it continues to report this issue, then mark it a false positive and rest assured that all is well.

The reason I feel that you should only trust this behavior if it is specified in the spec is that that is the only behavior that is guaranteed. A new version of your Servlet container or another container altogether might change this behavior. It is very unlikely you would detect such a change though it would lead your site vulnerable.


I found some weblinks which may give you an answer:

http://www.thespanner.co.uk/2012/05/01/xss-technique-without-parentheses/

http://blog.cinu.pl/2013/07/xss-parentheses-and-brackets-filter.html

Let me conclude the answers:

 >

or

 >

However, you can see that Blacklisting doesn't work. The XSS Filter Evasion List shows tons of possibilities how to trick a filter. You should rather escape the input proper.


Both cookies and localstorage are accessed via JavaScript APIs. When the attacker can inject JavaScript into the target's html document, they can read and write them equally.

A comment mentions http-only cookies. But those can not be accessed by client-sided JavaScript applications at all, so they are not competing with localstorage in most scenarios.

But one thing you need to keep in mind is that there is no such thing as a javascript-only cookie. When you store confidential information in a cookie, that information will be sent to the server with every request. When you don't use https, then it will be sent unencrypted. This has nothing to do with XSS injections, though.


Storing password along with encrypted file

While there's no obvious vulnerability here, a better option is simply to store a static string, rather than the key itself. If an attacker finds a side-channel attack which allows them to discover one block of plaintext, your approach would leak the passphrase and thus break the whole system, whereas the fixed text option would not.


How does the ipv4 option "record route" work?

It is not uncommon for this option to be blocked by ISPs.  Since you are getting no route information at all, the router closest to you (i.e. your home or office router) is probably black-holing those packets.  If you can reconfigure that device, you may well find that you can get little or no more information from downstream for the same reason.


That is not the source IP of the request, it's the value of what the user agent set in the Host header.

When I make a HTTP request to StackExchange to fetch this question page, it looks like this:

GET /questions/169836/http-requests-from-server-itself HTTP/1.1
Host: security.stackexchange.com
...

The Host header indicates that I wish to load from the security.stackexchange.com host, and is usually automatically filled by my browser when I make a request. It knows the host because it's in the full URL I'm visiting.

The header allows one server to host multiple sites on multiple domains via virtual hosting. One HTTP server on one IP address can host multiple sites with different domain names (each pointing to the same IP via DNS) differentiated by the content of the Host header sent by the user agent (e.g. a browser).

What you're seeing is either requests someone made manually by going to http://1.2.3.4 or requests made by automated systems that scan the internet. In the case of the latter, they likely scan by IP space only and do not know the correct hostname for the system, so simply provide a Host header with the IP address in.

In summary: these requests are not being made from your own webserver, and I would not say this is a security concern.


Is the order of cipher suites related to the client's preferences ?

The order in the ClientHello shows what the client prefers, i.e. the preferred ciphers are on top. The server is still free to ignore this order and pick what it thinks is best. Often there is a related setting in the TLS configuration of the server, like SSLHonorCipherOrder for apache or ssl_prefer_server_ciphers for nginx.  Cloudflare at least makes use of the clients preference to optimize the connection. From Do the ChaCha: better mobile performance with cryptography:

  CloudFlare is able to intelligently choose whether to choose AES or
  ChaCha/Poly for different clients based on the client’s advertised
  cipher preference. For recent Intel processors, we use the standard
  AES-GCM algorithm. For browsers on machines that do not have a
  hardware AES chip, we prefer the ChaCha20-Poly1305.

Also RFC 5246 (TLS 1.2) says in section 7.4.1.2 ClientHello:

cipher_suites
  This is a list of the cryptographic options supported by the
  client, with the client's first preference first. ...


Can a full SSD or HDD recover deleted data?

There are three main types of storage drives. Hard disk drives, solid state drives, and solid state hybrid drives. Each of them behaves differently.
Hard Disk Drives
When you delete a file, you unlink it, effectively telling the filesystem that the sectors in which the file resides are no longer in use and are free to be overwritten. When this happens, the file is said to be present in unallocated space. Filling up an entire drive, in theory, will fill up every sector, including the ones which the unlinked file resided in, overwriting it. This is true for hard drives in most cases (rare exceptions include when a sector on a hard drive goes bad, and the hard drive is unable to write to it, causing the damaged data to be stuck in place). In general, you can assume that a single overwrite of any given sector is sufficient to destroy the underlying data. Random data is often said to be better than zeros. If you are on Linux, you should probably avoid using /dev/urandom as it is very slow. A very fast and sufficiently random alternative to create a random file to fill up all your free space would be the following:
# key=$(head -c 16 /dev/urandom | base64)
# sync
# openssl aes-128-ctr -nosalt -k $key -in /dev/zero -out /fillfile
# sync
# rm /fillfile
# sync

It's important to do this as root because some filesystems, such as ext4, have a certain amount of the filesystem reserved for the root user only. On ext4, this is 5% of the entire drive space by default. This is designed to prevent a regular user from filling up the entire drive and preventing daemons running as root from writing their important log files to the disk. However it also interferes with filling up the entire disk, so you must create the random file using root.
You can test if your drive has any bad sectors with the smartctl command. Install the smartmontools package, and run the following:
# smartctl -A /dev/sda | grep Reallocated_Sector_Ct | grep -o '[0-9]*$'

This should output the number of bad sectors on your drive. The first command lists a bunch of data about drive errors, the second command singles out the error related to bad sectors, and the third command displays only the last number, which is the raw value of relocated (bad) sectors in the drive's lifetime. In most cases, this value will be 0. If the number is higher, some data may still be left over on your drive. In theory, this could contain sensitive information. Each sector's size is typically 512 bytes (or 4096 bytes on some modern drives). If the number is very large, then you've got other problems to worry about, because your drive is about to fail soon, and you should probably back it up and wipe it before it dies on you. Note that this issue applies to solid state drives as well.
Solid State Drives
SSDs are a bit different. They contain an extra area called overprovisioning space, which is not accessible by the operating system. Due to wear leveling, filling the entire drive may not actually delete all your previous data, and files in unallocated space may remain in the overprovisioning space. Each time you fully fill up an SSD, you have only a statistical chance of overwriting any given sector, and there's a small chance that the sector will not be overwritten, and will instead be part of the overprovisioning space. Now, you can issue the TRIM command to some SSDs, which tells the firmware to erase the contents of all unallocated space. However, you have to trust the firmware to do it properly, and many do not. Additionally, there is no research on whether or not TRIM destroys data in a way that ensures it cannot be recovered with specialized hardware, as far as I am aware, even if you could trust the firmware to erase cells promptly.
(Since I wrote this, there is evidence of data being recovered from erased flash memory, even after multiple writes.)
On Linux, you can mount your filesystem with the discard option, or you can periodically run the command fstrim / (with / replaced with the mountpoint of any SSD you want to TRIM). Using fstrim has less overhead. Doing this is good for performance, and also helps make sure that data which is deleted is harder to recover. If you use disk encryption, you may want to avoid using TRIM however, for reasons this article explains quite nicely.
Solid State Hybrid Drives
SSHDs are hard drives which contain a small (several GiB) built in solid state drive which they use for caching reads and writes in order to speed up the drive without being as expensive as a full solid state drive. I don't believe you can issue the TRIM command to these drives, or even control the solid state component of these drives at all. The behavior of these drives is entirely dependent on the firmware of the drives, and is entirely unpredictable. Such drives could easily send all consecutive writes to the hard drive platter and only send random writes to the solid state drive, causing a large file used to overwrite the drive to overwrite none of the solid state drive at all, leaving plenty of sensitive data there. I would not use these drives if you want to be able to overwrite files at a whim.
Instead, if you need to hybridize an HDD and SSD, you could buy a small caching SSD and a larger HDD, and combine them using software such as bcache, which is far more efficient than crappy SSHD firmware, but also easier to wipe data off of if you need to. To wipe data off of them, you can disconnect the caching drive, essentially turning the system back into a regular HDD, then securely erase everything from the SSD, fill the HDD with a large file, and reconnect the SSD and turn it back into caching drive.
In summary, it's not easy to securely overwrite data by filling your hard drive with a large file. There are so many caveats to be aware of. If there is any chance that sensitive files may ever touch your hard drive, you should use full disk encryption. That is the only way to ensure your data is secure.


Aren't the hashes calculated with md5(password+salt)? ...

No they aren't. Looking at the source code of md5crypt you will see that is is way more complex. For one, it does not start with passwd+salt at all but starts with passwd$1$salt and then feeds another md5 based on passwd and salt into this hash etc. Thus very different and more complex than your assumption, whatever this assumption was based on.

See also https://pthree.org/2015/08/07/md5crypt-explained/ for a more detailed description of the algorithm including python code.


Web Application Using Identity Federation & OTP

This depends on the Identity Provider (IdP) you are using for this purpose.

Case 1 : IdP supports validating TOTP
If your IdP supports validating the TOTP, then you can directly call the api and don't need to store any secret key in your app db.

Case 2 : IdP doesn't support 2FA
In this case, you will  have to store the secret key for each user and validate the TOTP in your app itself.

Example : In Shibboleth you can use this with Shibboleth-IdP3-TOTP-Auth extension, whereas some IdPs only supports SMS-based 2-factor authentication.
Baiscally, You have to go with the IdP specification, unless you can choose the IdP. If you have a choice, go for those which supports various kind of multi-factor authentication (TOTP, SMS, Hardware tokens, etc)


Is there a strong challenge to be made against the startup executive that believes security must be delayed?

As I commented originally in the other question, Security cannot be the primary, or even a principle concern. Sometimes, during certain phases of the startup, you really need to focus on rapidly developing the features needed to drive the product, and patch security as necessary. Security can easily get in the way of operations, employee productivity, and slow down development. Although if yours is a security-related product or business, you might certainly need bulletproof security from the beginning, you really can't generalize and say that all businesses should focus on security from the beginning. (Sony, being large enough, needs to learn a lot of lessons about software development in the new century, not just about security.)

That said, security practices and practical security should be a factor on the mind of all technical employees. Where can you add security without getting in people's way? There's no such thing as 100% secure, so how much security is enough?


Which type of authentication is not prone to man-in-the-middle attacks?

Authentications based on key exchange methods are immune to MitM attacks by design. They do require some kind of certificate infrastructure, however. (note that the key exchange itself does not provide authentication)

Authentications based on shared secrets, public-key cryptography or certificates can also be designed to be immune to MitM attacks. Such authentications can include challenge-response mechanisms.

Two- (or multi-) factor authentication is not immune to MitM attacks, however Eve needs to be able to simultaneously intercept all the channels used, which dramatically increases the difficulty for her.

The basic idea of doing authentication that is safe from MitM is to do in sequence:

establish a secure (i.e. MitM-protected) channel
establish the identity of the other party
exchange authentication information

This is how your online banking is set up. DH key exchange + suitable encryption for step 1. Certificates based on a trusted root CA for step 2, standard web-form authentication for step 3.

Note that TAN lists (shared secrets), pseudo-random TAN generators (shared secrets) or SMS TANs (2FA) are often used additionally, but typically after the actual authentication.


ASN.1 encapsulated BITSTRING type in openSSL

You really can't know that without knowing what type of data you are parsing.

If you know what type of data you are decoding, then you should use ASN modules and related documentation to adjust your parser. In addition, you may need to make some intellectual work.

  the BITSTRING will only contain a buffer (like in case of the signature)

it is not a raw buffer, it may be a nested type as well. For example, if you look at ECDSA signatures, you will find that encoded signature is nested complex type:

ECDSA-Sig-Value ::= SEQUENCE {
    r  INTEGER,
    s  INTEGER
   }

and here is how it looks:

  or will encapsulate some other types(like in the public key case)

Again, not always. RSA key uses nested structure in BIT_STRING, EC key does not:

these are just examples where your assumptions fail. Signature may have nested structure, public key may not have it. It depends on a context and without documentation it is hard to tell what to expect. So I would suggest to use the documentation. For example, RFC5912 that contains most PKIX ASN modules.

if you don't know what data you are parsing, then you have to do a hard work to proactively check whether the current type is primitive or constructed (without CONSTRUCTED bit set). That is attempt to unroll nested type if possible.

I have a general-purpose raw parser to decode ASN binary data to discrete structures written in C#: Asn1DerParser.NET and parser class: Asn1Reader


Is code-signing with a non-ssl timestamp unsafe?

Short answer: in general, no.

Long answer: the timestamp is a digitally signed data and it contains nothing that should be private on its own. It can't be reused and, as every other aspect of the system is properly conceived, cannot be counterfeit.

The critical element is that the timestamp comes from an authority that is trusted by both the initial signer and the final validator.

Now, there are edge cases where this timestamp element could lead to security issues if it is intercepted (for instance if the hash value contains in the timestamp can reveal important information about the data itself) but they almost all originate in other part of the system being broken (for instance, the use of a weak hash or the use of a hash in an insecure manner - like an anonymizer scheme).


Why does the linux XRDP module use a 512 bit RSA key?

Basically it is not safe. As far as I know, they use 512-bit RSA because they mimic what Microsoft's RDP server used to do, which indeed implied a 512-bit RSA key; using something bigger would risk breaking compatibility with existing clients. Biggest issue, though, is not that the 512-bit key is weak because too short; the main problem is that, as a client, you have no way to make sure that the key is see is indeed the one from the genuine server. Man-in-the-Middle attacks are a plausible possibility, and increasing the key size to 2048 bits would not help in any way.

Relationship of RDP with security is complicated and convoluted. The protocol has historically used its own embedded security system, something roughly SSL-like, but never analysed with any decent level of detail. Previously it did not even encrypt anything, or just the user password. If you want security with RDP, you should use it within a VPN; on Linux, consider SSH as a way to initiate cheap but robust tunnels. Microsoft pushes their own mechanism, called Remote Desktop Gateway -- basically wrapping the complete protocol into a regular SSL tunnel.


Can the following function be somehow exploited/used for malicious behaviour?

Your code looks good and there doesn't appear to be anything you need to be worried about.

A side note or two:

I would consider adding trim() to your variable to clean any white space.

I am a little curious why you use if(!empty){}if(empty){} instead of an if(!empty){}else{}


Which security documents do providers typically share with their customers?

This question verges upon opinion-based, but I'll try and provide some suggestions based on my experience (which is biased towards PCI but touches on others).  It isn't specific to the cloud but I believe there's an equivalence.

Some rules of thumb:

Attestations / summaries are distributed, reports are generally not
Policies are more likely shared than distributed
Formal audits are often subject to distribution limits

Some more information on these ROT:

Audits and scans often come in multiple levels.  For example, a PCI audit will result in a ROC (Report On Compliance) and an AOC (Attestation Of Compliance).  The former is a fully detailed report, and the latter is a quick summary.  The AOC is for distribution, and the ROC is not.  And - in the case of PCI - the AOC is not considered fully authoritative; the Service Provider Listing on the card brands' site is what customers are directed to for an authoritative source (compliance can be invalidated within a reports valid timeframe...)

The same is generally true of scans.  Detailed scan results, which list items that are not desirable even if they aren't fully non-compliant, are almost never distributed.  Top-level reports which list whether or not items existed are pretty much it.

When it comes to policies, these are generally handed out only grudgingly.  A common practice is to permit partners to come onsite to view the policies rather than distributing them.  This both ensures the security of the policies from distribution and subtly discourages partners from going through the trouble of coming to get them.

This is very one-sided, by the way.  I've worked for a large bank which required copies of security policies for company that wanted to integrate anything with them.  They're in a position to demand that, and they do.  The client of a bank or a service provider, however, lacks the leverage required to demand the same.  Also, what I said about the ROC and AOC - the ROC must be handed up the ladder to the Card Brands; that's what it for.  But it's never shared downward.

Finally, be aware that limits may apply.  If you have a contract, then it may include contractual obligations.  Large customers will often demand clauses that allow them access to things, or even to audit the service provider on a regular basis.  Some auditors place distribution limits on their full audit report, and in the case of SSAE16 SOC 2 report, distribution is disallowed by default.


What would running a VPN client over a VPN router actually do?

Interesting question. What it would actually do is route your traffic from your device to secondary VPN's endpoint through your routers VPN endpoint. Theoretically, it would add another layer of security, although depending on your threat model, this layer may be considered security via obscurity. And of course, this will slow down your connection speed and increase overhead.

Without more details, I will take a blind stab at this and ask: What is your threat model? What are you trying to achieve with this setup? I will hypothesize a couple of scenarios in which one may wish to do this:

If you don't trust your router, lan, ISP, local government, or gateway VPN's endpoint, than it may be worth the performance hit because (properly configured) it would protect you from attacks on your LAN, and it would hide your real IP address from your device's VPN provider/server.

If you don't trust the client's VPN provider or server's ISP or government... (if you are in the USA also remember that you actually have more legal protections [or so they say] with traffic that does not leave the United States -- traffic routed overseas actually is easier to legally intercept in certain cases) , than this setup (used properly) would effectively hide your IP address.

If you don't trust whatever services you are connecting to, than it never hurts to have another layer to make it harder to trace the orgin of your traffic, but be careful of common gotchas such as web-rtc leaks and other user created points of failure.

In general, this setup would add little anonymity and could be defeated by traffic analysis, application level bugs/backdoors, and most importantly; mistakes made by the user (the user is usually the weakest link in any security chain).

However, it would make it more difficult for someone trying to track your web activities to obtain all of necessary log files (depending on the integrity of the VPN providers [or their ISP's] and the legal jurisdiction that the services are hosted in).

If your threat model is an intelligence agency or something like that, than a better setup would be to use a chain of proxies (some of which can be tor) in conjunction with your VPN. The exact setup you would want would depend on what you are trying to achieve (ie, do you want to proxy into your VPN, or access a chain of proxies through the VPN, or some combination thereof?). Personally I would use something like Whonix, routed through a VPN server, and use an anonymous VPS server as your final hop (change it frequently and be careful about sending any data through this final exit that can personally identity you, otherwise this is all a waste of time).

As always, do not leave an audit trail -- whether that be using a credit card in your name to pay for both services, or not taking the proper precautions to hide the source of your traffic while setting up your configuration. I recommend implementing tor into your setup for scenarios that require high anonymity. However, I would not rely on tor alone.

Personally I like to do something such like client > VPN > Tor > [randomly selected and frequently changed anonymous proxy server] > destination. Be careful about that final hop though. If you can deal with being captcha'd all over the place, omit it because it can act as a single point of failure defeating all of your efforts.

In conclusion, define your threat model, do much research, and make an informed decision about how much performance you should, or are willing to sacrifice to gain security and/or anonymity. Hope that helps.


Does concealing server software versions have a notable effect on security?

The question is regarding "Security through obscurity"1. Does hiding your design/implementation (e.g. what server you are running) lead to less instances of exploitation? This is a long debated subject with reasonable arguments on both sides of the fence.

All security practices are a tradeoff between cost (e.g. effort, maintainability, money) and benefit (reduced instances of exploitation, reduced impact of those inevitable instances). In this case the cost is the effort it takes to change the string and the benefit is some degree of obscurity. However, (as you noted) in a targeted attack (and by that I mean someone is determined to get into your systems) there are other methods of canceling out that benefit (e.g. looking at default error pages, default files, obscure stuff like cookie handling, and pwning something else). In a non-targeted attack (and by that I mean some skiddie looking for low hanging fruit or a dumb automated piece of software scanning the internet, same thing) you avoid harassment.

HOWEVER, the actions needed to secure against a targeted attack (regular updates, access controls, sane configuration, good data hygiene) would protect against aforementioned non-targeted attacks. These are by far the best bang for the buck and what you should be doing.

So, if you are out of other things to do, then go ahead and hide your server tokens. It'll stop people from noticing low hanging fruit if you are super late applying patches or something else fails. However, note that in that case you may already be dead in the water. So if there is anything left, your time is better spent attending to that or asking good questions like this one.

Personally I prefer adding humorous server tokens to make attackers laugh or incorrect server tokens to confuse them. minorcrash.com (when up) currently has DOM injection that renders a picture of a cat being hit by a snowball.


Cloud provider or self-hosted for key-storage?

Unsure whether it is or not relevant, but IMHO the most secure server for an internet based thread is an offline server.

If it is possible for your use case, I would keep the syncing service offline most of the time to reduce the possible attack times, and then put it online only when I would need to sync something, if possible after ensuring that all security patches have been applied. An alternative way would be to only use a limited access private network, but this is often a dead end way.


Does altering characters of a file url lead to another file?

The chance is N in 153,803,885,110,405,674,678,434,597,293,100,547,399,764,930,461,696 where N is the number of files stored under /file/d with public view permissions set (TY @Mike Ounsworth).

So, there's a chance, but it's not a great one.

The "garbage string" is a 28-digit name which appears to consist of uppercase letters (26), lowercase letters (26), and numbers (10).  So each digit can be one of 62 characters.  The number of possible combinations for that string are therefore 62^28.


Javascript injection in email address as username?

I would say that theoretically (and practically, depending on your sanitation function), yes, the local part of an email can be used in XSS attacks.

The problem is that email addresses are complex and may include a number of special characters. Additionally, email addresses offer features such as comments and quoted strings, which allow even more special characters.

XSS in Local Part of Email Address

[I'm using the informational rfc3696, because it's a lot nicer to read than the official rfcs.]

  The exact rule is that any ASCII character, including control characters, may appear quoted, or in a quoted string.

So a valid email address would be:

""@example.com

You can test its validity here. This is obviously not secure.

Further Possibilities

Even without quoted strings, an attacker can at least get close:

  Without quotes, local-parts may consist of any combination of
    alphabetic characters, digits, or any of the special characters
       ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

This is already enough to enter a javascript context, eg:

email me

via:

foo'onclick='alert'foo='@example.com

The problem here is that ( is not allowed, but I would not be comfortable printing this to the enduser unencoded. At the very least, a user could change the style: foo'style='color:red'title='imImportant'@example.com.

You can also place the payload inside a comment of the local part, so possible restrictions of your email provider do not apply, eg: ("")me@gmail.com, where me@gmail.com is your email address (here, the same rules as above apply - < and > can only be inside quoted strings; additionally, you cannot have ( and ), even in quoted strings).

And this is just about the local part. The domain part gives an attacker additional attack vectors.

Proper Defense

This is why XSS prevention should not be about filtering, but proper encoding. All dangerous characters (in most contexts - but not all -  these are at least ', ", <, and >) should be HTML encoded when send to a user, no matter what filter was applied beforehand.


Is it possible to ensure client data is correct?

To put it simply: There is NO way

As you already determined, a request can easily be forged.
Even if using a custom encryption, your users can decompile your code and find out how it's done.

The only way to prevent users from tampering and decompiling your code is by not handing it to them.

Often this is done by providing SaaS products that run server sided.

All you can do is try to obfuscate your code if you need to serve the application as such.

But note: Security through obscurity is NOT secure.

P.S: Even if your users do not tamper requests: GPS coordinates of mobile devices can easily be spoofed.


Video Conference Systems - Security Testing

I have had limited exposure to this - but the main attack routes I have found successful in Video and VOIP have always been misconfigured H.323 gateways - it can be very difficult to set up H.323 and the associated protocols correctly, as each vendor seems to implement things differently. Symantec had a useful list of 20 rules in  this paper - well worth having a look.


How long to wait before publishing a web vulnerability?

If the company you are publishing a vulnerability for is your employer, it's never a good idea to publish the vulnerability. You may be a whistleblower, but you will likely lose your job for neglecting your responsibilities.

Publishing responsible disclosure applies mainly to external party who neither has a duty to the company and whose livelihood is not dependant on the company. The main reason for responsible disclosure is because it is in the public's interest to know about the issue, as well as for taking credit for the discovery which can allow you to build a reputation/resume. However, running a vulnerability scanning tool like wpscan is not really considered an original research, there isn't really much credit to gain here.

As an employee of the company though, you really should fight this from the inside. You are part of the company and you are in a much better position than an external party to push for the resolution of the vulnerability.

  How long should I wait before publishing them?

You should only publish the issue if you are ready to leave the company if the issue isn't resolved. Alternatively, if you judge that it is in the public's best interest to know about the issue, then you may want to go the whistleblower's route and publish it anyway if you think losing your job is a good enough cost for the greater good of public interest.

Although, do note that not all security vulnerabilities are of public interest. A vulnerability that simply allows users to deface the company's site, for example, are embarrassing for the company, but really serves no public benefit. A vulnerability that allows you to launch a nuclear rocket to anywhere in the world or allow the NSA to do dragnet snooping, on the other hand, would definitely be of public interest. And there are lots in between them.


The Center for Internet Security Benchmarks tend to be my go to source for hardening advice. They will, of course, need to be tailored to your environment, but I have found them to be fairly general purpose and easily modified. On the linked download page you will find both IIS and SQL Server documents.

As for the other half of your question, it seems like you're asking for additional hardening advice on the underlying operating system. If so, then see this question as a starting point - Windows Hardening. If that does not fit your needs, then I would suggest formulating a separate question specifically on that topic.

While hardening the underlying layers is good, you also need to be concerned with the web applications as well. The metrics that I've seen seem to indicate that compromises are shifting away from the OS and servers and focusing on the web apps themselves. So don't forget to look into that as well.


Security concerns of running auto-login script on server-side?

This is extremely common practice already, think database connections on servers with most keys stored in plain text on the server, there is little way around it.

You just have to prepare your self for automation:

Ensure the connection is only 443 (SSL or what ever port the SSL is on for this service)
if you access the server physically ensure you only have the required ports open to complete the tasks the server requires.
if you have to SSH to the server ensure you use a password and a cert for the connection

it is as the comments say, secure the server and its activities, do not focus on the password, just ensure its not in a publicly touchable file (away from any web servers) and read only for the user who needs to read it with no permissions to anyone else.

The only list of concerns would be this:

automated logins mean automated connections, you need to ensure you are not getting MitM attacked by putting extra security in, its easier to attack an automated connection (no one there to read the warnings!!)
Where, when and who can read that password file.
security of the server and who can access it

dont forget to ensure that all your passwords are randomly generated and stored in an encrypted keychain if you have a cert then 8 random characters will be enough :)


This has more to do with risk management. You do not have any contract with Facebook or Twitter. So you have a risk that they may change the contents of the JavaScript file without you knowing. This can be malicious or accidental, either way you have no control of this risk.

So unless you get a contract with the external party which moves the liability to them, there is nothing else you can do and you should store the sources locally.


While @schroeder's answer addresses the basic process for signature validation, there is an important step missing. The recipient needs to have a copy of your public key, received and/or validated from a trustworthy source, in order to verify your signature. Without a pre-existing trust in your public key, or in a signing authority which has validated your key, validation of the electronic signature is effectively pointless since the key could really belong to anyone.

The most common way this is handled for PGP systems, as @JayFromA pointed out in his comment is via a Web of Trust. An alternative method, typically used in enterprise environments, is Public Key Infrastructure. Both methods are essentially based on the same process though.

All clients must be configured to trust the public key(s) of one or more signing authorities.

In a Web of Trust, signing authorities can pretty much be anyone whose public key has been received and/or verified from a trustworthy source. The important part here is making sure that the keys you trust to vouch for the authenticity of other keys are themselves authentic, known to be well guarded against abuse, and belonging to users who are sufficiently diligent in verifying ownership of the keys they sign. At some point, this should involve some form of out-of-band communications such as a face-to-face meeting otherwise you've put yourself into a "turtles all the way down" trust model.
In a PKI system, one key will be assigned the role of Root Certificate Authority (Root CA) and will probably delegate its signing authority to a select few other CAs by signing their keys. Since this trust is enforced at the enterprise level (or built in to some applications, e.g. web browsers) it's generally very difficult for end-users to personally verify the trustworthiness of the public keys or signing practices of the Root CAs (and, by extension, their delegates). It is also imperative that the Root CA be extremely well guarded, and that the activity of all CAs is regularly monitored for abuse.

When a new client is added, their public key must be signed by a trusted signing authority in order to be trusted by existing clients.

In a Web of Trust system, the key may be signed by one or more users. Generally, a key's trustworthiness is increased by the number of trustworthy signatures on that key. Of course, trust can be placed in the key directly (and then you may choose to sign it yourself as well) if you have properly verified it out-of-band and you are confident in the user's ability to protect it.
In a PKI system, trust in the key is usually established by signature from a delegate CA. The Root CA should never be used, except to establish new delegates or revoke the trust of existing delegates when needed.

When any client wants to communicate with another, they must exchange public keys according to the protection intended for the communications. If the communication is to be signed, the recipient will need the sender's public key. If the communication is to be encrypted, the sender will need the recipient's public key. If it is to be both signed and encrypted, both users will need each others' public keys. An important thing to note here is that only public keys should be exchanged - nobody should ever be allowed possession or control of a private key that is not their own.

For both Web of Trust and PKI systems, this can be handled via any number of ways. Most commonly, public keys are published to a key server. However, they can also be transferred via e-mail attachment, removable storage, or any other electronic media. It's also quite possible, for some formats, to exchange keys on paper. However, transferring a key reliably from paper back into a computer system is hardly practical.

From here, steps 1-3 in @schroeder's answer apply for the signing process. After the message is composed, the sender generates an electronic signature (hash of the message, encrypted with the sender's private key) and attaches it to the message. The rest of this process is essentially handled the same regardless of whether you're using a Web of Trust or PKI.
Upon receiving the message, the first step in verifying the signature is to verify the trustworthiness of the key that should have signed it. If a key exchange (step 3 here) hasn't happened previously, the recipient must obtain the sender's public key by some means. Once they've obtained the key, they need to verify the chain of trust for that key. This essentially entails validating that the sender's key has been signed as described in step 2. If the electronic signature(s) on the sender's key cannot be traced back to one or more trusted signing authorities, then the sender's key (and therefore the received message) should not be trusted.
After the sender's public key has been verified (and perhaps, depending on the client software's configuration, regardless of it) the recipient will attempt to decrypt the electronic signature with the sender's public key. If decryption fails the message should not be trusted because this means it was signed with a key other than the one known to belong to the sender, and that the recipient will not be able to follow the next step since they don't have the proper key to use for decryption.
After the signature has been successfully decrypted, the recipient generates a hash of the message and compares it to the one provided in the signature. Though the specific algorithms used for this may differ, the process is effectively the same for both Web of Trust and PKI systems. If the hash generated by the recipient does not match the one included in the signature, that means the message has been altered in transit and should not be trusted.
Depending on the configuration, the recipient's client software will probably display the message to the user along with some indications of the results from the signature analysis. If anything went wrong with the signature verification in steps 6 or 7, or the trustworthiness of the sender's public key could not be verified in step 5, the client software will probably put up some red flags indicating that the user should not trust the origin or integrity of the message. At this point, it's up to the user to decide whether additional validation is needed before actually trusting the message themselves.

All that being said, most people receiving PGP-signed messages - and especially those without proper software to support it - probably just follow the XKCD validation method.


PHP file upload: Order of security measures

Yes, you should first validate the file, then move it.

If you move it first, validate it, and then delete it if it is invalid, an attacker would have a small window where an attack may be possible.

Apart from that, tmp_name is safe to use as it is not user-controlled, so there is no reason to avoid using it. Note also that the finfo mime type check can be bypassed in some situations. That is also one of the reasons to change the filename. Directory traversal is generally not possible with "name" from $_FILES, but renaming the file - including the extension - can prevent execution of the file as PHP file (additional defenses would eg be to store the file outside of the web root so that it can't be accessed directly).


What is a more secure network topology, star or mesh?

Some ideas:

For monitoring a star network might be more convenient because it is sufficient to monitor the central nodes.
For damage mitigation a mesh network might be better because there is no single point of failure like in a star.
For privacy a mesh network might be better because usually in these all clients are assumed to be equal so there is no server to authenticate clients against and clients might just be replaced by seemingly different clients.

The statement in your material was probably made with some ideas about what mesh and star networks are used for in the mind. If the precise definition of star and mesh networks supports these claims depends on the definitions you are using.

I hope my examples give you an idea why people might have made these claims, though.


Do these mysql and ssh issues mean my rails server was hacked?

It doesn't sound like you were hacked to me, it sounds more likely that Slicehost had some sort of issue temporarily. The SSH message you got means that the key that was sent by the server was different from the one in your cache. Here are possible reasons that come to mind:
- Another server may have been temporarily assigned the IP address, and then the problem was fixed.
- The ssh service started up before all file systems were available and it responded improperly. Once the server was completely up sshd responded properly
- Slicehost proxy incoming ssh connections somehow, and while the server was unavailable it responded with a default of some kind

I would not associate the symptoms with getting hacked, it sounds much more like a network/server infrastructure problem, so I would start with contacting Slicehost and asking them to correlate your problem with any events. A good company should own up to any issues they may have had at the time. If there were no events then you need to do a thorough check of your system as it is still possible you got hacked.


Do any of you who are *really* dealing with APT have any recommended intelligence feeds for SIEM/IDS/etc?

Due to the sensitive nature of APT and that it is closely aligned to espionage, the only real way to get a suitable feed will be through Government or National Law Enforcement agencies.

The difficulty will be in establishing a level of trust to enable the sharing of information.

For organisations within the USA, the advice is to contact your local FBI field office and arrange for a threat briefing on the subject.

For organisations within the UK, then making contact with CPNI (Centre for the Protection of National Infrastructure) would be the best option. CPNI hold a number of industry specific 'Information Exchange' forums that may be of help. However it is worth noting that CPNI has a focus on the critical national infrastructure for the UK and if your organisation falls outside of this may impact on access to that.


Whichever version you decide to use you will have to implement a formal lock-down and security maintenance programme for your systems and there won't be much difference between the major versions (Centos, Debian or Ubuntu for example). They all need careful install, lock-down, and patching/monitoring/managing.

I have a number of clients who successfully use Centos and Ubuntu (!4.10 LTS) which, together with appropriate configuration, patching, and montitoring regimes pass level 1 PCS-DSS audit each year without issue.

Apache and Nginx will both be fine for PCI-DSS applications as long as they are also patched, configured securely and monitored etc. It's not really the software (within reason) but the way you use them that's important to PCI.


That answer is most likely. It depends on the verification depth (or lack of) from the issuing certificate authority.

With that being said, it sounds like you will still be breaking policy even if you find a CA that will issue a certificate based on email verification alone.

Are you willing to suffer the repercussions if/when caught?


Single Domain SSL Certificate vs Wildcard Certificate

Wildcard certificates are not much costly as you think, I bought wildcard certificate at $42 for one year, which I think it is affordable. https://www.ssl2buy.com/wildcard-ssl-certificate

There is difference between single and wildcard certificate because a standard certificate can secure only your single website and wildcard certificate can secure unlimited numbers of sub domains.

When you order single certificate you should generate CSR for domain name like www.example.com that can secure both version of website www and non-www. If you want to secure sub-domains, you should add * asterisk before domain name like *.example.com.

As per your question, If you are buying a single certificate and generates CSR for *.example.com, certificate authority will not verify your order and doesn’t send certificate file.


How can HelloSign be secure without any authentication?

how could the document-signing service verify that someone who signed
  a particular document really did so?

They don't. They do create a log showing the IP address of the remote computer that issued the "signature"; but they can't identify the legal entity that caused the signature to be made. If the identity of the signer turns out to be in dispute, the parties to the dispute can assemble evidence about that later on.

This sort of functionality is provided in the meat world by a notary public or the medallion signature guarantee system.


SQL vulnerable if input type = email check is enabled

SQL injection is a server-side vulnerability. It has almost nothing to do with your client-side code. If you do all your validation on the front end, what happens when a malicious user decides to not use your front-end at all, but instead send requests directly to the server?

So, this does not protect against SQL injection at all. To properly protect against SQL injection, implement server-side protections. You can use a modern web framework and/or ORM that completely abstracts SQL away, or follow the OWASP Cheatsheet.


How can I improve the security of my protected branches in GitHub/GitLab?

I believe Git doesn't have any authentication related features except providing your credentials to the hosting service you are using when you try to push.

That's why the option to "protect" a branch is relying on the hosting service and is implemented differently from one service to another.

The security of this system depends on the security of the hosting service itself.


Securing a file from getting stolen in an Android application?

You are out of luck here. If you want the file to be used on users phones, you will have to live with the fact that the file can be stolen. Encryption doesn't really help here, since you need to store the key somewhere on the phone. A sneaky user can just steal the key and decrypt the file themself.

You can make it more or less complicated to gain access to the file by obfuscating in various ways, but in the end you are playing a loosing game here. If the contents of the file must not be stolen, you need to rethink your architecture. Whatever is done with the file has to happend on the server side instead of on the client, so that the client no longer needs the file.


Accidentally downloaded a Trojan.Dropper which Malwarebytes picked up, how to ensure system is clean?

A third option (which imho is a bit better than just using the regular scan but obviously not as safe as a complete reinstall) would be to use a (or even better multiple) rescue disc that many of the antivirus companies offer (like  this <- haven't tried that particular one, just the first one google threw at me).

These allow to scan the system when it is not running which makes it a bit harder for the malware to hide.
If you happen to be from germany you could also give  desinfec't a shot. It's not free but it's a rescue disc that uses multiple engines to scan you pc (amongst other things) and quite a handy tool.


Fuzzing authenticated part of web application

As you asked for other tools, here's a vote for the (amazing) Python Requests library. It makes writing your own tools way easier than it used to be. Writing automated logins is dead easy.


Windows Certificate Store - Generating / importing personal certificates using a smartcard?

For the most part, smartcard integrations requiring pointing your email client at your smartcard reader & middleware, ensuring the proper crypto library is selected.  There is mucho information on doing this with both OpenPGP smartcards and x509 smartcards

Depending on the email client, the Windows trust store can be used, or not used.

Your operating system does not actually require access to the private key.  Instead, you interact with the private key through the smartcard reader and middleware.  Your authentication step (typing in the PIN) enables the smartcard to perform decryption or authentication events on your behalf then.  Performing this crypto-offload on the smartcard is more secure since the private key is on the smartcard, not exposed to the file system, and stealing your private key is no longer easy.

Putty-CAC & Smartcard integration

To register Putty-CAC with a working smartcard, assuming your smartcard reader and middleware are already installed and working:

Execute Putty-CAC
Scroll down to SSH & expand it
select CAPI
Select Cert and Browse
Select the smartcard certificate that corresponds to the cert you want to use
Use that for setting up SSH on the remote host

Technically, this is only RSA based SSH, not certificate based SSH, so you will miss out on some of the nifty security features of certificates

You can find expanded instructions here

Certificate Registration

Some middleware, such as ActivIdentity which is very popular, include a function for registering certificates with the Windows.

Activclient > smartcard reader > My Certificates > Select Certificate > Make available to WIndows

Additionally see the following:

Encrypting Messages w/ SMIME in Outlook Webapp

Thunderbird DoD Smartcard Configuration

Using an OpenPGP Smartcard


Here is a article with the data I hope you needed:

There you can find two files with password and small statistics


Which self assessment questionairre should I use for PCI DSS compliance

Unfortunately for you, because the raw card data transits your servers in cleartext, you have to use SAQ D, and because you aren't the merchant yourself, it would be SAQ D for Service Providers.

There may be entire sections of the SAQ that don't apply to you and can just be marked N/A, but you still have to fill out the whole thing.

If you could get the upstream system to encrypt the card data in a way that only Paycorp can decrypt (public key cryptography is good for this), you'll no longer have cleartext card numbers, and can probably use a shorter SAQ - or at least be able to mark even more of SAQ D as N/A.  But if that's not an option, you're stuck with it.  Sorry.


What's the fastest protocol to target for password attacks

I haven't precisely done what you're describing, but I would expect most online bruteforce and dictionary attacks to quickly run into account lockout thresholds.

One workaround for this is password spraying - trying just a few of the most common passwords against many accounts. Unless the environment's controls are tuned to detect such activity, you're likely to get at least a few valid credentials without detection - and by distributing such an attack across many protocols, you might be less likely to be detected!

But in practice, you'll almost always find this unnecessary -- because it's more efficient and reliable to exploit an unpatched system, steal credentials or hashes from that system, pass (or crack) the hashes, pivot to another system with higher-privileged credentials, and repeat until you acquire the target level of access.

Edit: I see now in your comments that the artificial lab environment that you're working with explicitly has no lockout thresholds (not usually a real-world scenario).

Of likely available protocols (including the ones that you've listed), I would expect DC-based LDAP to be the service most likely to be A) already tuned for high performance, and b) have direct access to the back-end authentication data (eliminating performance issues related to a secondary service that must then relay the authentication attempts to the back-end AD infrastructure).

I would expect a high-speed Hydra attack directly against AD LDAP, in parallel against all available DCs (including read-only DCs), to be the most likely way to even start to approach the saturation point of the aggregate back-end AD authentication capacity. Theoretically, to increase per-source throughput, you could distribute hydra to all available workstations and servers in the environment.


How can I check my program for vulnerabilities over TCP?

You can attempt to look for classes of vulnerabilities, but the complexity of the code will likely exhaust you before you exhaust even the smallest possibility space.  This is why compiler aware machine learning fuzzers exist.

Check out american fuzzy lop: https://en.wikipedia.org/wiki/American_fuzzy_lop_(fuzzer)

You build a small, contained test program that calls your network logic directly with 'network data' provided by the fuzzer. The fuzzer will manipulate a 'zoo' of samples (data files in a directory) making changes to the samples and calling your logic.  It is best to manually capture (wireshark) some tests and extract the client packets for each response to a sample file for the fuzzer.  It is smart enough to recognize a nonce provided in the samples.

It found a 1 in 4.4 billion infinite loop for me in a few seconds.
With the right options and a bit of engineering it can even find your read beyond buffer errors.

It helps if your response logic is already well encapsulated and doesn't reach out to slow services (like the network) on every message.
You do not want it to write to your DB.
This will probably require some special initialization of your state to either accept the same nonce code for the duration of a test run or you should forcibly set a valid nonce into the data for each call.  Happily one of the capabilities of the fuzzer is to copy your state and reset it before each variation.  If the nonce is set during session initialization before any client response data, this performance option will set you free.

If it wasn't obvious you'll need to bypass SSL functionality for this test executable.

Of course other testing solutions exist, like Selenium, but the focus is different.  You want to find all the vulnerabilities with minimal test generation effort, and get reliable reproduction?  American fuzzy lop.


“Systems that are configured to allow booting to other operating systems” encompass two situations:

A computer with dual boot between two operating systems (e.g. Windows 2003 and Windows 8, or Windows 2003 and Linux) where the two operating systems have different user databases, and in particular different groups of people have administrative access. An administrator on OS 1 can read the swap from OS 2. This is of limited impact as the administrator on OS 1 can also read the data from OS 2, but it does mean that data which was accessed from OS 2 and never explicitly saved to disk is at risk.
A computer (typically a laptop) which is stolen by an attacker while powered off, or a computer whose hard disk is stolen by an attacker. The attacker has access to the storage medium unfettered so can read all the data on the disk.

Wiping the swap area on shutdown ensures that any data that wasn't explicitly saved to disk, will be properly erased after a clean shutdown. Data can end up on the disk implicitly due to swapping. Note that in practice, data can end up on disk for other reasons due to application design, e.g. temporary files, print and mail spools, browser cache, …

Wiping the swap on clean shutdown is of limited impact, because in some scenarios (e.g. attacker stealing a running laptop) you cannot rely on a clean shutdown. Some Linux distributions encrypt the swap area with a random key which changes at each boot (I have no idea if Windows can do this). This doesn't protect against warm boot attacks where the attacker can dump the content of the RAM, nor against sensitive data left in files.


The question is really broad and will most likely be closed as too broad.  Here are some tips:

disconnect from the internet
turn everything off
Borrow a laptop from someone else
reset your router back to factory
Use the laptop to connect to the reset router and change the admin user name and password and SSID
Take any computer on your network and boot from a boot disk and start over.  Make sure you have your files backed up.  Google on how to secure your operating system; that's too broad to do here
Invest in a good anti-malware program
Never use default passwords again
At that point, you might consider reconnecting to the internet

There are probably a lot more things you can do, but this should be a good start.


Why http microsoft connection in netstat check?

I don't know know what connections in particular you observed, but here are some candidates that a Windows service (the background tasks or "daemons" that run in svchost.exe processes) might be using:

Reporting basic diagnostics and telemetry. Lots of software does some of this but Win10 in particular has a lot of telemetry that lets Microsoft know things about how the OS is used, and most people don't disable it (it's actually quite hard to disable on most Win10 editions). The data is not supposed to be personally identifying or tied to a specific user, so there's no particular need for it to be secure.
Checking for or retrieving Windows updates. I would certainly expect this to be done over a secure connection, although in theory with enough signatures and timestamping on the traffic TLS isn't required for security (it's not like the patches themselves are secret, they just absolutely must not be tampered with).
As part of Windows Defender, checking whether unrecognized files have been categorized as safe or not (it generally doesn't need to transmit the files themselves for this, just a non-reversible cryptographic hash, though it might upload the full files sometimes). Like the update checks, this is something I would expect to be done over TLS but in theory doesn't have to be.
Retrieving certificates or related metadata from Microsoft (which issues its own certificates and also provides updates to the Windows ones sometimes). Since certificates are inherently signed - their entire security hinges upon it - this can and often is done over insecure connections (a TLS server sends its certificate to the client over plain text as part of, but before actually establishing the secure connection).
Querying Microsoft servers for the time, to help keep your PC synchronized. This is often done over an insecure protocol but it's usually NTP (Network Time Protocal) which uses UDP on port 123, rather than HTTP which uses TCP on port 80.
Checking for updates to, or downloading packages for, "Windows Store" apps. As with the Windows Update possibility, I'd be surprised if this wasn't using a secure connection.

There are probably many more that I missed, but those seem like some of the most likely to be running unexpectedly in the background, as a Windows service, and communicating with Microsoft.
Doing a reverse DNS lookup on the IP address (where you try to see what domain names are associated with the IP address), or examining the network traffic (using a tool such as Wireshark or Microsoft Message Analyzer), might help you determine what that connection is being used for.
Incidentally, Windows ships with a graphical utility called Resource Monitor that can, among other things, provide a real-time view of network connections and traffic similar to netstat, and may make it easier to trace the connection back to the service owning it.


Is it secure to store the salt along with the hashed password in the database?

but if i get access to the database and see what salt was used to that password i can create a rainbow table with that salt no

Yes you can, but it would only work that one password. The whole point of rainbow tables is that you can compute one once and reuse it again and again. The per-password salt means that each password hash must be attacked individually.

So to answer the question, no, the salt is not a secret.


Is a TPM module insecure if not soldered to the board?

The purpose of TPM is to protect the encryption keys used to encrypt disks with BitLocker.

If you can remove a TPM, as-well-as the disks, then you may be handing the key over with the lock, though in the case of a micro server, I suspect you're more at risk of someone stealing the whole server.

It sounds from your post like you're not planning to implement BitLocker's PBA features, so it may be worth asking yourself which problem are you trying to solve by implementing BitLocker.