Should I use CSRF protection on Rest API endpoints?

I wasn't originally aiming for a self-answer, but after more reading I've come up with what I believe to be a comprehensive answer that also explains why some might still be interested in CSRF protection on REST endpoints.

No cookies = No CSRF

It really is that simple.  Browsers send cookies along with all requests.  CSRF attacks depend upon this behavior.  If you do not use cookies, and don't rely on cookies for authentication, then there is absolutely no room for CSRF attacks, and no reason to put in CSRF protection.  If you have cookies, especially if you use them for authentication, then you need CSRF protection.  If all you want to know is "Do I need CSRF protection for my API endpoint?" you can stop right here and leave with your answer.  Otherwise, the devil is in the details.

h/t to paj28: While cookies are the primary attack vector for CSRF attacks, you are also vulnerable if you use HTTP/Basic authentication.  More generally, if the browser is able automatically pass along login credentials for your app, then CSRF matters.  In my experience cookies are the most common technology being exploited to make CSRF happen, but there are some other authentication methods that are used which can result in the same vulnerability.

REST = Stateless

If you ask someone "what is REST" you will get variety of answers that discuss a variety of different properties.  You can see as much because someone asked that question on stack overflow: https://stackoverflow.com/questions/671118/what-exactly-is-restful-programming

One property of REST that I have always relied upon is that it is stateless.  The application itself has state of course.  If you can't store data in a database somewhere, your application is going to be pretty limited.  In this case though, stateless has a very specific and important meaning: REST applications don't track state for the client-side application.  If you are using sessions, then you are (almost certainly) keeping track of client-side state, and you are not a REST-full application.  So an application that uses sessions (especially for logins) that are tracked via cookies is not a REST-full application (IMO), and is certainly vulnerable to CSRF attacks, even if it otherwise looks like a REST application.

I think it is worth a quick note that one reason that client-side statelessness is important for REST applications is that the ability of intermediaries to cache responses is also a desirable part of the REST paradigm.  As long as the application is tracking client-side state, caching is not possible.

Rest ≠ Cookieless

For these reasons, I initially assumed that a fully-compliant REST application would never need sessions, never need cookies, and therefore never need CSRF security.  However, there is at least one use-case that may prefer cookies anyway: persistent logins.

Consider a typical client-side (in this case browser, not mobile) web application.  You get started by logging in, which uses a REST API to validate user credentials and in return is given a token to authorize future requests.  For single page applications, you can just keep that token in memory, but doing so will effectively log the user out if they close the page.  As a result, it would be good to persist the state somewhere that can last longer than a single browser session.  Local storage is an option, but is also vulnerable to XSS attacks: a successful XSS attack can result in the attacker grabbing your login tokens and sending them off to the attacker to be used at their discretion.

For this reason, I have seen some suggest using cookies to store login tokens.  With a cookie you can set the http-only flag, which prevents the application from reading the cookie after it is set.  As a result, in the event of an XSS attack, the attacker can still make calls on your behalf, but they can't walk away with the authorization token all together.  This use of cookies doesn't directly violate the statelessness requirement of REST because the server still isn't tracking client-side state.  It is just looking for authentication credentials in a cookie, rather than the header.

I mention this because it is potentially a legitimate reason to use cookies with a REST API, although it is obviously up to a given application to balance the various security and usability concerns.  I would personally try to avoid using cookies with REST APIs, but there may very well be reasons to use them anyway.  Either way, the overall answer is simple: if you are using cookies (or other authentication methods that the browser can do automatically) then you need CSRF protection.  If you aren't using cookies then you don't.


You already mentioned that the AH header precedes the ESP header when applying both. Consequently the ESP header doesn't have any effect on the AH header. But the AH header can be used to protect the IP header when using transport mode and to protect the ESP header for both modes. But this is not very common and requires an additional Security Association for each direction. Thus you will end up with 4 SAs instead of 2 if you have a bi-directional connection.

Furthermore the hash used by AH is a cryptographic hash. You can't change/recalculate it without knowing the key.


Could you please share errors written at console ?

This type of contents does not send to browser over js files, I believe you can find it in a response of document request or initial response. Most of the time you can find it at html response or API response (json/xml etc.).

If you want to check XSS, follow items listed below.

Find the input at response (alert(1)@gmail.com
Check, is app do html encoding/decoding (write <> and check response is <> or <>)
If it does not handle correctly, find the right payload

You are working with stored XSS so you can follow this link https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002)

You can find out example payloads at link written below
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

PS. This situations can be a simple frontend error so check the reason first (reason of "loading tickets").


website legitimate or not, how to evaluate?

why am I getting a security notification even when the site relates to Redhat ?

Because it uses a certificate that is not trusted by your browser (or OS).

This appears to be an CA used by Red Hat, for instance for https://subscription.rhn.redhat.com/ as well. The common thing for these sites are that they are mainly useful if you're running Red Hat. I suspect that they include this CA in RHEL, allowing verification of the certificates by the sites.

Furthermore, those sites do request a client certificate for authentication:

$ openssl s_client -port 443 -host cdn.redhat.com
[...]
---
Acceptable client certificate CA names
/C=US/ST=North Carolina/O=Red Hat, Inc./OU=Red Hat Network/CN=Red Hat Entitlement Operations Authority/emailAddress=ca-support@redhat.com
/C=US/ST=North Carolina/L=Raleigh/O=Red Hat, Inc./OU=Red Hat Network/CN=Entitlement Master CA/emailAddress=ca-support@redhat.com
/C=US/ST=North Carolina/O=Red Hat, Inc./OU=Red Hat Network/CN=Red Hat Candlepin Authority/emailAddress=ca-support@redhat.com
[...]

This indicates that their CA issues certificates that clients uses to authenticate against Red Hat's servers. This requires that they control the CA.

Getting the CA into the roots of browsers is probably not worth-while as clients will not have any business on these sites, unless they have a client certificate. If they have a client certificate, installing the root certificate as well is trivial, if it's not included in RHEL by default.

Edit: This is likely wrong
This would somewhat improve security from Red Hat's point of view: they don't have to rely on external parties for securing their own infrastructure. They can peg the update clients to that single CA, which they fully control. If this is done, it would stop any other CA to act as MiTM.

When it comes to evaluating security, the steps I did to check was the following:

Verify that it's really redhat.com, and not some similar name with e.g. Cyrillic characters.
Check certificates OU and Common Name. I googled these two, which gave me this article from RedHat, which indeed verifies that they use these OU's and CN's.


Use header instead of cookie for CSRF double submit cookies?

The reason to use double submit (instead of a synchronizer token) is that you do not want to have to do a lookup on the server for every request. So as long as the value of the cookie matches that of the request parameter the request will be passed through.

That works because evil.com can neither read cookies from example.com (and thereby send a matching request parameter), nor set them (and thereby set both to some arbitrary constant).

You are correct to point out that this fails for subdomains. It is possible for evil.example.com to set a coockie that will be used for example.com, and thereby bypassing the test. So if you do not trust your subdomains, do not use this solution for CSRF protrection!

Now, does your proposal solve the problem? No. It actually makes it worse. Since you do not need to read or modify any cookie value anymore, it comes down to being able to modify request headers. So this is the same as just relying on a single header with a constant value, e.g. the commonly used:

X-Requested-With: XMLHttpRequest

You have two problems here:

You are still vulnerable to an attack from evil.example.com since a subdomain can modify request parameters to its parents by using document.domain.
You might also be vulnerable to attacks from evil.com since there have been multiple Flash exploits allowing you to set headers for cross domain requests.


How to determine how entropy changes when using uppercase, numbers and special characters in a dictionary based passphrase?

As long you:

make such changes either randomly, or globally (for example, by capitalizing every word);
you add all of the resulting words to your dictionary; and
you continue to select words randomly for your passphrases

... then your entropy simply increases with the number of words.

But if you're doing anything non-random and non-global to transform the text, then you're adding complexity for which its strict Shannon entropy is much less relevant than its "real-world" entropy (how hard it is to crack). This is because your resistance to cracking would then depend solely upon the obscurity of your method, which would violate Kerckhoffs' Principle and is therefore not recommended.

In my opinion, you're far better off either adding a word to the passphrase, or increasing the size of the dictionary (which you could certainly do by tweaking the words as you've suggested, as long as it's random or global).

I personally only capitalize, add numbers, add punctuation, etc. to my passphrases in order to comply with naive complexity requirements, and do not count these towards the effective entropy in any way. Trying to do so randomly makes them too hard to remember (which is the whole point of a passphrase), so I actually have a method (cap the first letter, and then add "2" and "!" to the end).

And since I do not rely on those tweaks to increase the entropy, I'm not shy about disclosing the method publicly. Kerckhoffs would be proud. ;)


What is the difference between login throttling and temporary account lockout?

A) Yep you got it. Same in that they both result from a failed login attempt(s), though they differ in things like logging, the resulting UX implementation, and when one is used.

If a user is temporarily locked out, this is email-worthy. You should send an email or text-message to them notifying them that enough failed attempts were made to warrant a temporary lockout. This is an opportunity to empower the user to intervene in the event that it isn't them attempting to log in.

Alternatively you could use just a lockout timer in minutes, but requiring action from the user to unlock the account would be more ideal.

Throttling is more for pacing. "hold your horses, take a breath" and can be done without even informing the user. A simple UI spinner element can be used to prevent the user from accidental double-form-submits and prevent rapid attempts over the span of seconds as opposed to minutes or hours.

This can also be used as an opportunity to detect bruteforce attempts if the attacker isn't going through your UI. If 3 attempts are made per second but your UI only allows 1 attempt every 3 seconds, something is amiss.


If by "private client/server" you mean "nobody but me has access to them", what you're doing seem to be overkill. And since your Encryp/Decryp method is private and derived, it may weaken the encryption if not implemented correctly.

This seem to be a classic case for a symmetric key encryption; just generate a 128/256 bit master AES key, and embed it in both binaries. Generate an encryption key+IV on client, and send it to the server with a checksum, encrypted by your master AES key. Then use it for communication. No need for DH.


Is there a risk connecting to POP3 or SMTP email server without secure connection?

Is there a risk to sending and receiving emails via without a secure SSL/TLS connection?

The problem is equivalent to using your webmail via plain HTTP. A man-in-the-middle attacker could capture the emails you exchange with the server and sniff your login credentials as they are sent in plain text.

Such an attack is possible for someone in the same Wifi as you, your roommate, your employer or your ISP - it is particularly easy for everyone who processes the traffic on the way between you and the server, but it's usually not feasible for a remote attacker (like a friend who's attacking you from their home).

So, if you do it in your private home network and don't fear your ISP logging your data1, you're fine. In a public Wifi however, it's a serious risk - especially because email clients usually contact the server periodically in the background without your interaction. So, as opposed to using your webmail, you would not send your password just once in the beginning, but broadcast it every 15 minutes to check for updates.

(Also note that it's particularly easy for an attacker to automatically extract POP3/IMAP/SMTP credentials from the traffic as their transmission is part of the respective protocol. For a webmail login form, they would at least have to search through the HTTP traffic to find the request where the password is transmitted.)

1In your case, the ISP is the mail provider so they obviously already have access to that information.


Should the Keygen element be used to create a certificate for mutual auth TLS? What alternatives are there?

I think that there are many disadvantages in using the keygen element, as it is already enumerated in your post. If you have a webservice that should be easily accessible and compatible with a lot clients, it is quite hard to implement client-side authentication using keygen, a solution that is quite new and not very mature.

The best solution would be to provide cryptographic tokens to your clients, with preloaded certificates, signed by your CA. Of course, this adds a lot of complexity, because you have to manage the generation and distribution of the client certificates, which may be very hard to do if you have many clients and no infrastructure for a CA. The advantage of this solution would be a very strong authentication mechanism for your clients.

If you are just trying to prevent MITM attacks, using SSL and a good user/password access mechanism may be enough in most cases.

It depends a lot on what are the resources you have, what your are trying to protect and against whom and who are the users of your application. Answering this questions would be the first step in the process of building a secure systems.

Update:

In regards to the threat model you have described, I do no think that your model will offer protection against compromised CA. Here is an example:

A CA is compromised and a certificate is issued for your domain
The DNS of the client is compromised so that it responds with the IP of the attacker, when queried for your domain
The client tries to connect, it establishes a connection with the rogue server, which in turn connects to your server
The rogue server acts as a client that connects from a new device and a new client certificate is generated.
Even if the real client sends his existing certificate, the rogue server would ignore it.

The attack described above assumes that a client can have multiple certificates (one for each device he is connecting from). If you do not want to implement this behavior, then it would be quite hard for a regular client to copy the certificate to every device he is using and of course, a bad user experience .

All in all, protecting against compromised CAs is tough business, and I think that as long as new technologies as DNSEC are not implemented at a large scale, there is not much one can do.

On the other side, the hacking of a well known CA is not something that happens every day. Just be sure that you do not buy a certificate from a noname CA and you should be secure enough for the moment.


If you connected to your Google account on your work computer, your employer may know your login credentials. Your employer may employ a TLS proxy, which allows them to inspect TLS secured traffic (e.g. HTTPS traffic). If this is the case, they could also see the contents of emails as they are transferred from Google's servers to your work computer.

However, that does not mean that your employer would actually do that. I'm not a lawyer, so please don't expect legal advice from me, but it is common for employees to sign various policies, especially regarding to what is monitored on their work computer.

In general, you have to expect that an employer can see everything you do on their computer. That doesn't mean they actually do look, just that they can.

As for reading your emails when you are on your home PC, your employer can not read those, even if you have connected to that account previously on your work PC. Theoretically, an employer who knows your credentials can attempt to log into your Gmail account, although that would most likely be illegal in most jurisdictions, and get them in deep trouble. Furthermore, you will likely get a security alert if a new unknown device attempts to log into your Gmail account.

In order to ensure the security of your account, I would advise you not to check your private emails on your work computer and to set up 2FA authentication.


Can a phishing website use the original (HTTPS, TLS) certificate?

If one has a phishing website that uses the original certificate that was obtained by accessing that website,

No it cannot, because it does not have access to the original website's private key. If it could, the whole PKI would make no sense at all.

  can an attack fool users to believe they are accessing legitimate websites?

Yes, but using means other than the original certificate.

  If not, how will it get caught?

The phishing website will not "get caught". User will not see a correct certificate in the client's browser.


The trouble, as described in the conmments, is that there is no way to be "100%" sure.  Anything you can devise to check might be compromised.  You can look at the running processes, but the program that shows them to you might be lying.  The system might be communicating with the bad guys in ways you can't imagine.  You can get a known clean system to watch the network, but your system might be sending out exotic packets that you don't know about, or subtly blinking the caps-lock light, or signalling by pulsing the wifi strength in Morse code.

Your only recourse is to completely start over from a known state.  Otherwise, you can be "mostly sure".


Digital signature without exposing the private key

The solution is to use cryptographic hardware like Hardware Security Module (HSM) or personal device is Cryptographic USB Token or Smartcard.  These devices store private key securely on board. Private key never comes out of the device but hash or content to be signed goes in the device and device provides (PKCS11) API to do the cryptographic operations using the key.


How secure are virtual machines really? False sense of security?

VMs can definitely cross over.  Usually you have them networked, so any malware with a network component (i.e. worms) will propagate to wherever their addressing/routing allows them to.  Regular viruses tend to only operate in usermode, so while they couldn't communicate overtly, they could still set up a covert channel.  If you are sharing CPUs, a busy process on one VM can effectively communicate state to another VM (that's your prototypical timing covert channel).  Storage covert channel would be a bit harder as the virtual disks tend to have a hard limit on them, so unless you have a system that can over-commit disk space, it should not be an issue.
The most interesting approach to securing VMs is called the Separation Kernel.  It's a result of John Rushby's 1981 paper which basically states that in order to have VMs isolated in a manner that could be equivalent to physical separation, the computer must export its resources to specific VMs in a way where at no point any resource that can store state is shared between VMs.  This has deep consequences, as it requires the underlying computer architecture to be designed in a way in which this can be carried out in a non-bypassable manner.
30yrs after this paper, we finally have few products that claim to do it.  x86 isn't the greatest platform for it, as there are many instructions that cannot be virtualized, to fully support the 'no sharing' idea.  It is also not very practical for common systems, as to have four VMs, you'd need four harddrives hanging off four disk controllers, four video cards, four USB controllers with four mice, etc..
2020 update:  all the recent hardware based vulnerabilities (Meltdown,Spectre,Foreshadow,ZombieLoad,CacheOut,SPOILER,etc) family of vulnerabilities are great examples of how VM's are always going to be able to communicate, simply because they share hardware (caches, TLB, branch prediction, TSX, SGX) that were never intended or prepared to be partitioned and isolated.


I've decided to not use bcrypt, since it looks like it is designed for weak passwords that need salting, which a cryptographically random 256 bit number definitely isn't. The current approach is:

Create a token based on a SHA256 sum of the 256 bit secret plus a serialization of the expiry date.
Send this token to the user that wants to invite others, as part of a link.
The receiving user that wants to join a group clicks the link, and the server validates that, given the SHA sum and the expiry date, the token is not expired and the sums match when doing the same calculation again.

Any comments on the validity of this approach are greatly appreciated.


Nmap SSL service detection: How to check all open ports only for SSL service?

You can reduce the number of probes that Nmap sends by using the --version-intensity option. This option takes an integer argument between 1 and 9, limiting the number of probes sent to open ports to those with a rarity of that number or less.

The probe for SSL/TLS (SSLv3 and newer) has a rarity of 1, so you could get away with a simple --version-intensity 1. As a convenience, here are some mnemonic options and their intensity equivalences:

--version-light = --version-intensity 2
--version-all = --version-intensity 9
default = --version-intensity 7

If this is still too much, you can copy the probes (and matches!) you are interested in into a separate file and specify it with the --versiondb option.


OpenBSD-based LiveCD/LiveDVD - is it secure? is it offical?

One security problem with a LiveCD is that its static and there for cannot be updated.  The SQL Slammer worm was memory resident, it doesn't matter if you have a disk drive.  You can install live cd's onto usb drives using LiveUSB Creator.

Check out the new Debian GNU/kFreeBSD distribution.   You have all the power of apt and its built on a FreeBSD kernel.


HTML Copy Paste To Get Info From Infected Computer

It depends on the possible malware and the files. Generally I would open the computer case, remove the HDD, attach it to another PC readonly (there are writeblockers) and copy the binary files. This could be one simple and comfortable solution.


Am I in this particular case allowed, to store password in java program?

I would store the password only in memory at runtime, but this has one drawback. You need to type in the password every time you start/restart the server. This is the most secure way to managed plaintext passwords.

Plus I would followed the advice to r00t, create two users on the MySQL server, one with read permission and one with write permission. Just in case someone was able to gain access to your server and dump the memory.


How does using unsigned integers protect against integer overflow attacks?

Using unsigned integers does not prevent overflow. A k-bit variable can only represent 2k different values. No matter how you interpret the bits.

What you're probably referring to is the fact that signed integer overflow in C and C++ is undefined behavior. Which means that the C or C++ international standard does not specify any behavior of the program that triggers such overflow. Wrapping the value around or causing a run-time exception are valid options as much as opening an exploit shell. (Of course, no sane implementation would opt for the latter choice. But an exploit can become possible through further consequences.) Furthermore, the compiler is allowed to optimize based on the assumption that signed overflow does not occur and might, for example, optimize away misguided overflow checks such as if (x + 3 < x).

For unsigned integers, on the other hand, the C and C++ international standards require that the value wraps around as if arithmetic on a k-bit unsigned integer was done modulo 2k. This means that your program can rely on the wraparound and use it to its benefit. (Or to shoot itself into the foot.)

Other languages like Java mandate reliable wraparound also for signed integers. (Java doesn't even have unsigned integer types.)

Speaking of security, the largest threat posed by overflow, however, is that your application logic does not anticipate the wraparound. And this is a problem regardless of whether you are using signed or unsigned integer types. If your application logic assumes that for a request of n bytes, it needs to allocate a buffer of n + m bytes (for a small constant m used for, say, bookkeeping) and n happens to be less than m below the maximum value your integer can hold, wraparound will cause your program to allocate a too small buffer which, in turn, will be overrun. There goes the exploit.

If you want to be secure, instead of using unsigned integer arithmetic throughout, I recommend that you do the exact opposite: Use signed integer arithmetic and compile with UbSan. Unless your application is computation-heavy, it will have only minor run-time overhead but if the unanticipated event happens and your application overflows an integer, extra code added by the sanitizer will kill your application before an attacker can exploit it. A similar sanitizer for overflowing unsigned integer types cannot be written because the standard requires well-defined behavior for doing so and programs legitimately rely on it. This is actually one case where undefined behavior in the language can help make your application more secure.


Difference between Architecture review and a Design review

IT Engineering is part of the broader Systems and Software Engineering process, which has well defined stages that are taught in virtually every College and Trade School in the world.  In general there are numerous stages in the IT engineering process:  requirements, architecture, preliminary design, detailed design, integration and testing, security/penetration testing, staging, production, and operations.

So no, the Architecture stage does NOT include all aspects of design, cost estimation, material/component choice, documentation, and getting everything to work together, but does include planning.  All the rest are intentionally separate and further stages of the process.  An Architecture many times has an upper-limit cost target defined, plus may have some cost and schedule estimates of most-expensive components or critical-path sub-systems or components.  And sometimes may include some preliminary design of especially complex sub-systems of the IT Architecture.

Your IT architecture is a high level design of the overall major elements of the IT system and how they broadly interconnect: telecom, gateways, routing & switching, servers, desktops, remote access, security, etc.  Its review will need to answer questions about how the architecture meets requirements (for example, if remote access by employees is needed, how is that accomplished; or if there is a requirement for Internet facing servers yet protected back-end databases servers, what are the elements in the architecture that provide staged separation yet controlled access).  It is acceptable to have some unknowns and TBDs during the Architecture review ... ideally as few as possible but still this is a review of the conceptual vision for the IT system, not yet all its nitty-gritty details.

Design Reviews follow the Architecture Review, and there can be several Design Reviews depending on the complexity of the IT architecture.  The Design Review will fully describe the exact details of the IT system being proposed or being modified.  Some examples include:  what specific components (hardware and software) from which vendors and which models/versions (a bill of material aka BOM), what is the BOM's cost details (one-time and recurring), how specifically is the system maintained by the operations staff, what security tools are to-be in-place, how does the security operations staff use those tools daily, what is the routing plan, what is the IP addressing plan, what is the server loading and load-distribution plan (startup, typical, worst-case recurring, surge, and under-attack), what is the DNS implementation (external and internal), etc.  Each subsystem of the IT Architecture gets a detail review.

I would suggest you do some reading about IT Engineering and Systems Engineering ... there are all sorts of books available on a decent bookstore about this topic.  You can also search online for Enterprise IT Architecture Review checklists and Enterprise IT Detailed Design Review checklists ... some are available online from mostly the U.S. Govt and from Industry Standards bodies like The Open Group.


How much entropy should passphrases for encrypting ssh keys have?

It should be as resistant as a good passphrase (obligatory quote of xkcd, even though it does not relate to offline attacks (but another one does))).

The encryption mechanism used by ssh-keygen is slow - which is good. Since the answer will be changing with time as computational capacities increase, make it 25 characters long and you will be good to go for some time.


How to implement end to end encryption in multi platform messengers

I will try and answer what I - at the point of writing - understand is your questions:

Cryptography is platform independent, so it does not matter which platform is sending of receiving an encrypted message as long as the sender and receiver do adhere to the same protocol.

As to the key exchange: Let's say, you have devices A and B, both belonging to the same identity, I. Now, I is supposed to have access to messages through A and B. That either means each message is to be encrypted with key(A) and key(B) - or that key(A) = key(B).

In the first case, you cannot trust the server to not transparently add a third device under their control to the list of keys for I, i.e. key(C). This might raise some eyebrows with the sender, but as they are in control of the UI and for that - nevermind.

In the second case, you can share the keys by establishing a secure communications channel to transmit the key - for example by displaying a QR-Code on A and scanning it with B in a secure environment.

In both cases, as the UI and logic might me closed source or you might not be running the binary you have sources for (could be patched before delivery), you cannot be sure that either A nor B transmit all keys known to them to the server while you're texting away.

It boils down to: key exchange is a solvable problem for this scenario - trusting software isn't. You either do or don't and use your own software under your control, adhering to the same protocol.

As to you asking for the implementation and design details for a specific product: I don't know; it might not be disclosed. And if it were, if you're distrusting the supplier, why trust what They say?


How to prevent Apple and Google from accessing Telegram messages

Telegram uses the Firebase Cloud Messaging system for its push notifications on Android, and APNS (Apple's equivalent) on iOS devices. These notifications to the Telegram app on your phone come from the Google and Apple servers, respectively.
Telegram -> Push Service (Google/Apple/etc) -> phone -> app -> notification

So yes, the traffic is not coming from the Telegram servers directly, and that's why the app is showing you notifications when the Telegram servers are blocked in your country.
But no, those services do not have "access to your messages"; the messages are secured in the same way that messages are secured coming from the Telegram servers directly.
The data that the Telegram servers pass on to these services are encrypted using the same encryption as the app. Once the app receives the data, it decrypts it to show you the notification.
Can you stop using the Push Service? By disabling notifications, you might trigger the Telegram app to de-register from the push notification service, but that will depend on how the app is created. I have not found the relevant documentation to confirm that one way or the other.


What is the purpose of this "secure mail link open in browser"

Your question is very unclear but as far as I understood it, this agency sent you a link via email, and the link URL included your credentials, e.g.

https://agency.org/login.php?user=joojaa&password=abcd4321

Of course this is very insecure as URLs can be sniffed (HTTPS protects the content, not the identity of the URL being accessed) and in this case an eavesdropper would have access to your credentials.

Edit: as per OP's comment:

  Yes this is basically how it worked. exept there was no user just a really long password

it appears that the URL contained just a GUID, probably a one-time token. It is difficult to say whether this is secure or not; if this was for the activation of the OP's account, there's probably not to worry. On the other hand, if that token alone allows to login to the OP's account, that's very bad.

Related discussion here: Are GUIDs safe for one-time tokens?


Is using Google Authenticator to login from the same device secure?

Two-factor authentication has little to do with "air gap" in this case, and all to do with prevention of brute-forcing or password-guessing ("Something you know"), by requiring a second piece of information: "Something you have" (the app and its generated tokens).

The existence of the mobile app on your device + logging in from that device presents little in the way of a security hazard, unless of course your phone is already compromised, in which case the efficacy of two-factor authentication is not your primary concern.


Why is it necessary to match the checksum of a download with another file provided by the same server?

Really, when they are on the same site, there is no real security value.  It is only of a security value when trying to verify that a file from another source is the same file (though even that may be dubious thanks to success of collision attacks against a lot of typical error detection hashes.)  The primary reason, as you mentioned, is simply to make sure that you can validate the transmission was ok.


How to check if range of IP addresses are SPAM blacklisted?

Spamcop (like other DNSBLs) uses DNS to allow for quick lightweight lookups. Use the DNSBL client of your choosing, or roll your own.

Alternately, you can just contact spamcop and ask them for help. This might be the preferred solution since you have a lot of hosts to look up.


If I change my computer time, will it change the time I used VPN?

The VPN logs do not dictate time off of your computer, they dictate timestamps when the server gets connected to. So however, the sever is set-up, that will be the correct timestamp for login/logoff. Your computer has no control over the timestamps.


Is my bank's website secure, if it uses partial HTTPS?

The non-SSL download incurs the theoretical (and also practical) risk of being intercepted by an active attacker, who will make "something else" with it.

Javascript, by itself, cannot do downloads from outside of its own domain; that is the point of the Same-Origin Policy. Since the Javascript is loaded from the bank domain (foo.com) but the download is from l.longtailvideo.com, then one must assume that the Javascript instructed the browser to do the download, most probably by inserting an <img> tag in the page HTML.

Browsers are, generally speaking, quite well protected against malicious pictures; otherwise, you would get hacked when you do Google searches or access various forums, because in many forums one can embed links to external pictures.

In your case, the picture is the logo for a video player in Javascript/Flash (depending on what the browser can do); I think it is this one, although maybe an older version because their logo appears to have changed. This blog post indirectly tells us that the player with the logo you observe was the "latest version" more than two years ago.

What is the worst that could happen ? I suppose that the logo is displayed somewhere on the page. An industrious attacker could replace the logo contents with a picture of his own, possibly a bigger picture which would disrupt the page layout.

There are worse things, though. The attacker could return a HTTP "redirect" to make your browser send a GET request to any arbitrary other URL. You will probably find this past question interesting: it discusses what could happen with an <img> tag pointing to an attacker-controlled server. That applies to your case.

Anyway, the mere fact that your browser warns you is a bad thing: either the warning is important, and that's a security alert which should be treated as such; or the warning is spurious, and it trains the user into ignoring security warnings, which is not good at all in the long term.


Router D-Link 600 B1 EDB-ID-15666 Vulnerability

The router may still be communicating with the hacker's computer, and thwarting your attempts to repair it.  Try bypassing the malware by downloading the router's update file from a different network, such as a coffee shop, and save it. When you get home, disconnect your D-link from the internet, do a 'factory reset', reboot it, and then try uploading the new image to it.


Why use a USB WiFi adapter with Aircrack-ng?

The main reason is because you need the adapter to support monitoring mode.

This mode allows the adapter to not only sniff all packets coming from the AP to the clients but also from sniff the data from the clients to the AP.

  Can I use my WiFi USB adapter as a WiFi interface in my Kali VM ?

You can use it to get WiFi access but it will not work with aircrack-ng.

Notice: There are some computers that have the monitoring option built in the default adapter.

You can read more about it in this answer.


Does a username/password + emailed PIN count as strong 2FA?

From a pure security standpoint I wouldn't regard this as 2FA (which is traditionally defined as "two of something you know, something you have, something you are).

From a practical standpoint I can see some potential issues with this in an enterprise setting. In many companies login to applications is tied to Active Directory sign-in which is also used for access to the e-mail system, so an attacker with access to the users account username/password would likely also be able to get access to the token.

Even if they're not formally linked a lot of corporate users in my experience will practice a kind of informal single sign-on where they manually sync up their passwords for all corporate systems, so again an attacker with access to one will get access to the others, bypassing your 2FA.

If you consider another likely attack scenario (malware on the users PC) again it would bypass this requirement as it would be possible to access the users passwords for the application and e-mail service using a keylogger.

So in summary, I'd say that of your two options this is more an additional inconvenience in return for little gain.  If the risk profile of the application justifies 2FA, I'd look at full 2FA style solutions (e.g physical tokens or biometrics)


What real world benefits does PGP have over sending email with SSL/TLS such as with HTTPS?

SSL/TLS protects the email from tampering or eavesdropping as it transits between your computer and Google's server, and possibly during further relays to eventual recipient.  And that's all it does.

PGP does far more.  If you're sending a signed email, the recipient can verify that the email was sent by you, and that it was not tampered with at any point between when you wrote it and when they received it.  If you're sending an encrypted email, you know that nobody but the intended recipient can read it -- not Google, not the NSA, nobody. That's why it's called "End to End Encryption".

However, the email metadata (from, to, subject, timstamps) is still sent in clear, and PGP can't help with that. So in general, it's best to send PGP-encrypted emails via TLS-secured connections.


Should the bit-strength selection of a child certificate be influenced by the CA or the chain?

Short answer: Yes, there is some potential benefit for end-entities to choose a public key that is larger than the CA's public key.

The question is not entirely clear, but I presume your situation is that the root or parent uses a 1024-bit RSA key (i.e., the end-entity's cert is signed with a 1024-bit RSA key), and the end-entity uses a 2048-bit RSA key (i.e., the public key being certified and used by the end host is a 2048-bit RSA key).

In this situation, I can see two potential security benefits to using a 2048-bit end-entity cert instead of a 1024-bit end-entity cert:

You are safe against an attacker who can break 1024-bit RSA, but cannot break 2048-bit RSA, and can only eavesdrop but cannot (or is not willing to) actively tamper with connections.  In comparison, if you used a 1024-bit RSA key, then such an attacker could recover your RSA private key, eavesdrop on connections, and decrypt the encrypted traffic.
You are safe against an attacker who, five years from now, breaks 1024-bit RSA but cannot break 2048-bit RSA, assuming that the CA transition to 2048-bit RSA within the next few years (as many CAs are doing and many browsers are requiring).  This is because an attacker who is able to recover the CA's 1024-bit signing key five years from now does not gain anything by doing so, if that key is no longer valid.  The CA's signing key doesn't help the attacker decrypt any SSL-encrypted traffic he may have access to (not even old traffic he recorded long ago).  The only thing an attacker can do with a CA's signing key is sign a new bogus certificate and use it to mount a man-in-the-middle attack on users, but if the CA's root cert and 1024-bit public key is no longer accepted by browsers five years from now, that doesn't help the attacker at all: he's too late.

[In addition, there may be some key management benefits to choosing a 2048-bit key now and being able to continue using it for several years, even if you have to renew your cert to do so, as opposed to having to change keys in a year or two.  To be clear, this is not a security benefit; it is merely a potential logistical benefit, depending upon how annoying you find it to have to change your keys at some point in the future.]

Bottom line: There might be some benefit to choosing an end-entity key that is larger than the CA's key.  However, I don't want to claim the benefit is overwhelming, or that the size of the end-entity public key is all that matters.  Against a powerful attacker who is able and willing to mount active attacks, and who can break 1024-bit RSA within the lifetime of validity of the CA's root cert, you're probably hosed no matter what size public key you choose.


No, that means that the communication from your computer to the IMAP server is not encrypted.  You still need to send your username and password to the server, but it is visible to someone sniffing your network traffic.  I wouldn't recommend using that service.


Can I track delete action in event viewer?

Unfortunately the only events logging delete actions don't fit your requirements.

Both are logged on the system the file is located i.e. server side, and this wasn't even a Windows Server.
They are not enabled by default as this level of auditing might cause excessive logging.

  4656(S, F): A handle to an object was requested.

  This event indicates that specific access was requested for an object.
  The object could be a file system, kernel, or registry object, or a
  file system object on removable storage or a device.

  If access was declined, a Failure event is generated.

  This event generates only if the object’s SACL has the required ACE to
  handle the use of specific access rights.

  This event shows that access was requested, and the results of the
  request, but it doesn’t show that the operation was performed. To see
  that the operation was performed, check “4663(S): An attempt was
  made to access an object.”

You need to revise your backup procedures and implement some incremental backup that will keep storing deleted files.


How to exploit a  output that filters brackets but nothing else

Without any special preconditions (unusual codecs, etc.), <p>$XSS</p> is only vulnerable to XSS if opening angle brackets are allowed.

Without creating a tag, you can't inject content that's meaningful to your browser's HTML parser. Everything else, including fancy unicode, is just treated as plain data. However, you could make guesses about how the server prosseses the data to still achieve XSS. E.g., maybe the server converts ＜ (FULLWIDTH LESS-THAN SIGN U+FF1C) to an actual angle bracket on the way, or maybe &lt; is converted back to < for some odd reason - I've encountered that in the wild, but there is no indication that these tricks would work in your case.

  XSS doesn't seem to be an option with the bracket filter, but it seems like, since it is unfiltered, there should be some way to exploit it.

What other client-side vulnerabilities do you expect to encounter here? Besides XSS, keeping Unicode characters is often required for localization and doesn't cause any obvious security problems when printed in an HTML body.

That said, allowing arbitrary Unicode can be quite annoying (PoC: ก็็็็็็็็็็็็็็็็็็็็&) which is why many social websites (e.g. Facebook, Twitter) limit allowed characters. Here is how it renders in Firefox:


How Secure are Authenticity Token in Rails

Having a CSRF token in the body of the page is a standard way of preventing CSRF attacks. The token is different for every form that's presented by the application.  so when a form is submitted the submission can be checked for the validity of the token.

If an attacker takes a token from a page that he sees essentially that token won't be of use to him as when any other user visits the same page, the token won't be the same.

If you're looking for more information you could look at the OWASP page on CSRF or this post on StackOverflow about the rails specifics.


It's an FTP server from "scientia-ssdb":

http://www.linuxquestions.org/questions/linux-newbie-8/unable-to-list-the-directory-after-changing-ftp-port-from-21-a-4175454098/


The ETag header is used for effective caching of server side resources by the client. The server send an ETag header in the HTTP response to some string and the client caches the response content and associates the string given in the ETag header with it. If the client wants to access the same resource again it will send the given string within some If-None-Match header in the HTTP request and the server will only return the full content if the resource has been changed and otherwise tell the client that the cached content can be used. See Wikipedia for more details.

This means, that every client can get such an ETag header from the server, i.e. the value of the header is not secret. Thus contrary to your question the leakage of such a header itself is not the problem.

The problem is instead if the value of the header (i.e. the string) provides information about the server which should stay secret. Often the value of the header is just a hash over the content of the resource which is not a problem at all. But for example the Apache web server can base the ETag on the inode number, last modification time and/or size of the file. Using these meta information a unique ETag can be created much faster compared to computing the hash of the content. Only, at least the inode number is considered internal information to the server and should not be exposed to the client. While not be usable in attacks directly knowledge of lots of inode numbers can be used to gain for example information about the underlying file system which might help in further attacks against the server.

This means that the inode number should not be extractable from the ETag header because it should stay secret. This was fixed with Apache 1.3.27 (long ago), i.e. the inode number is still used to compute the ETag but in a way that it cannot be extracted from the ETag value.

  Edit: Rapid7 for example see's this as with a severity of four.

The CVSS score is computed from several parts. The details for this specific problem can be seen here but it essentially boils down to that it is trivial to use, can be done over the network, needs no authentication and provides some internal information about the server.


Web Crypto API maturity for JavaScript RSA encryption?

Support for the web crypto API is allright, but not perfect. According to caniuse.com it got 91.5% support:

You'll need to use prefixes for some older browsers, and deal with some inconsistencies in the IE 11 version of the API.
Older versions of IE than 11 have no support at all. But that's only a 0.3% of global usage.
Your big problems are two mobile browsers - Opera Mini (2.3%) and the Android browser (0.8%). They have no support. However, usage of these might vary across the world. Opera Mini, for instance, is big in the developing world but not so much elsewhere.

What's important here is that you need to completely disable your application (or at least the sensitive parts) if the crypto API is not supported. Falling back on something terrible such as Math.random is not an option. Telling 8.5% of your users they can't use your site might off course cause some PR problems...

I'd say you need to have a very special use case for this to be motivated. But you seem to be familiar with the criticism, so I will not reiterate that. Just make sure your problem isn't already solved by the correct use of HTTPS.


I'm not a crypto expert, but I have looked into attacks on WEP.  Assuming you've implemented the calculations correctly, there are two possible issues I'm aware of:

Some keys are unusually difficult to crack, requiring far more IVs than normal.  You may have picked one of them.
The attack is a known-plaintext attack.  Traditionally, the attack is performed using ARP packets because they can be identified easily and have a known prefix.  The attack won't work if you've got more than a few non-ARP packets mixed in with your ARP packets.


Is Windows Firewall suitable for running in a production environment?

I guess it is up to you and your experiences. We (the company I'm working for) are using Windows Firewall. As far as I know, a lot of small enterprises are running Windows Firewall. It is "only" a firewall, and is therefore not more secure than what you make it yourself. Consider it ACL (Access Control Lists) you specify what traffic you allow and what you do not.

I can recommend these two sites for you, if you consider using Windows Firewall.

This one is a "How to configure windows firewall in a small enterprise:
http://technet.microsoft.com/en-us/library/cc875816.aspx

And this one is a textfile provided by Microsoft with an Introduction to Advanced Configuration of Windows Firewall:
Introduction to Windows Firewall with Advanced Security


Central auth service redirecting to subdomain, using digital signature as auth token

One thing I can think of that may be problematic (if the user is POSTing to the subdomain) is that you don't sign the subdomain the user is trying to connect to. Let me try to give an example of the issue:

Let's say I have (valid) credentials for foo.example.com. I send (foo, username, password) to example.com/login and get back (sig=signed(id, timestamp)). Now I POST to bar.example.com/login with (id, timestamp, sig). bar.example.com/login will look at sig, verify that timestamp matches the signed data, and then log in the id that was signed. I'm now logged into bar.example.com. Oops.

So I'd say the not only need the user never see the sig, but giving the user the sig is actually a security issue. If you do send back sig to the user you need to do sig=signed(id, timestamp, subdomain) and the subdomain login needs to verify that it is the signed subdomain.


How to protect ftp account information in the source code of a program

There are a number of attack vectors in this scenario, so just hiding the password will not help:

any code that you give away to people can be manipulated. This means that an attacker can just set his high score to an arbitrary value
ftp, in the way you use it, is unencrypted, so the complete communication will show up in a network sniffer such as Wireshark
the attacker can just set a breakpoint on the constructor of the URL class (very simple but a bit annoying because there are usually many calls to new URL().
the attacker can decompile the source code and search for "new URL", obfuscating will not help because this method is part of the Java API and therefore cannot be obfuscated. If he cannot understand the source code, he can add debug output or just place the breakpoint at a better place.
the attacker can use byte code enhancing to add a logging message to the constructor of the URL class

So it does not really matter how and where you hide your ftp password.

The only good solution is to have a server which does the highscore calculation itself (and even this way has the issue of bots). You should at least use a protocol that supports encryption (https, sftp, ftps). You need to ensure that someone who learns the credentials cannot destroy the high score data of other users. This can be done by tight permissions that allow only the creation of new files in the ftps/sftp-server or by using a web application that accepts the data and store it itself.


How can Linux be secure if it allows for open source contributions from the public?

You are misunderstanding how open source software development works. Not just anyone can modify the kernel, so no "unknown developers from around the world" are submitting mysterious lines of code. In order to make changes directly, you have to be hired by the Linux Foundation or another organization that has access to commit privileges, not just pass a brief check. Everyone else can only suggest improvements (often in the form of a patch) on the public mailing lists, and hope that the official developers will accept their suggestions and make the changes on their behalf. The review of patches is quite intense and patches often have to go through many revisions before being accepted, sometimes with each line being criticized (often for the most trivial things).
This is not so different from closed source development. You could argue that anyone can make modifications to Microsoft Windows simply by looking for a job at Microsoft. The only difference is that open source software is more transparent about their development process.

With all of this code being submitted by unknown developers throughout the world, how can the security administrators make sure that there isn't any backdoor scripts being added onto the OS?

Everything added is reviewed. The only way to get a backdoor in would be to provide a patch that looks good, but which has an exploitable bug that you are aware of. This is possible, but quite unlikely. Developers don't need to be malicious to introduce bugs at staggering rates!

Aren't there like 15 million lines of code?

More, actually. However a large portion of this is for device drivers which you will never even use. The Linux kernel is monolithic, which means hardware-related code is put in the kernel. The core of the kernel itself is actually not that big. It only looks big when you count the fact that it also includes code from obscure karaoke microphone drivers that are not even present in your kernel.

Do the admins of the OS really understand every line of code and know for sure that people haven't submitted something that could corrupt the system such as malware, backdoors or spyware?

No, although some particularly savvy sysadmins do have a good knowledge of how the kernel works internally. There are quite a few eyes on the code in the Linux kernel looking for bugs. It is hard for them all to hide. Yes, it is possible that a bug was secretly introduced (after all, it was attempted and foiled a few times), but the painful truth is, such intentional bugs would be a drop in the water compared to all the naturally existing bugs that find their way into such a huge codebase.


How can I block an IP, if I'm getting many http requests in a second?

fail2ban is an easy-to-implement solution in these cases.

Add a block-all-dem-noobs.conf file to your filter.d directory, something like this

[Definition]
failregex = ^<HOST> -.*"GET.*

Translation: a RegExp to find GET requests

Then create a new entry in your jail.conf, something like this

[block-all-dem-noobs]
enabled = true
port = http,https
filter = block-all-dem-noobs
logpath = /var/log/httpd/access.log
maxretry = 100
findtime = 5
bantime = 600
action = iptables[name=HTTP, port=http, protocol=tcp]

Translation: Look through my access.log file, then block for 600 seconds (10 minutes) the IP addresses that made 100 requests in 5 seconds

One major drawback, though, is that this might produce false positives for NATed users, as they'll all appear as one IP address to you.


Why is nmap that slow on my system (ubuntu 14.04)?

You're running nmap at its default scan speed, which should take about 90 seconds to scan a local system.  If you want to scan faster, specify either -T4 or -T5 as the scanning speed.  Note that a faster speed can be less accurate if either the connection or the computer at the other end can't handle it, and is more likely to trigger firewalls or IDSs.


A SSL/TLS connection must always end with an alert message of some kind: a connection which is broken (e.g. the underlying TCP socket is closed) without an alert is said to be improperly terminated. The alert message for a normal termination is close_notify.

The handshake is only a part of the connection; a handshake occurs at the start and subsequent handshakes can be played on the same connection. The handshake is usually where errors occur, triggering alert messages, but a fatal alert message does not end only the handshake: it closes the whole connection.

In the case of a server requesting client authentication, the client may respond by sending a certificate and computing a signature; however, this is optional. The client is allowed not to honor the request. The server then chooses what to do. The server may reject the client right away, through an alert message which closes the connection. The server may also decide to continue, and handle the lack of client authentication at another level. A server which sends a Finished message certainly chooses to continue; possibly, the server may decide to report the error as applicative data within the tunnel (e.g., for a HTTPS server, send an HTTP error message once the handshake is finished).

See RFC 2246, section 7.4.6 for details:

   This is the first message the client can send after receiving a
   server hello done message. This message is only sent if the
   server requests a certificate. If no suitable certificate is
   available, the client should send a certificate message
   containing no certificates. If client authentication is required
   by the server for the handshake to continue, it may respond with
   a fatal handshake failure alert.

→ emphasis on "may".


Why does Windows 10 have so many open ports by default?

"Authorized Applications" does not equal "Open Ports."   These applications have authorization to communicate through the firewall...This does not mean that they're listening on ports open through the firewall.   In the case of many (if not all) of the application you listed, that means that when you open them and try to use them, they can establish connections to get the data requested.  If you don't open Twitter, it isn't listening.  If you do open Twitter, it still isn't listening on a port for in-bound connections.   The fact that it's an authorized application means that you expect the firewall to allow it to communicate as it is designed to do.  In this case, that's primarily going to be reaching out to the Twitter service to retrieve tweets.

So, while you are correct that you don't want services you don't need listening for inbound connections on open ports, that isn't what's happening here.


How to locate a domain controller on a Windows network when not a member?

Try type "any" or "SRV"
Did you query for the "any" DNS resource record (wildcard/pseudo) type? (Otherwise the default is to simple query for A records. And the records in question are in fact SRV RRs.)
(Also: you said you used type "all", I don't know if there is such a thing. What any does is translate to a query for resource record type 0x00FF, decimal 255. I checked with Wireshark. This translation is done by your client. I don't know all clients, but I can tell you that dig does NOT know of "type all" and NOT "type *" either and will give you an error. But dig will work nicely if you say "-t any".)
Using dig (if "example.com" is your Active Directory domain name):
dig _ldap._tcp.dc._msdcs.EXAMPLE.COM -t any
dig _ldap._tcp.dc._msdcs.EXAMPLE.COM -t srv

Using the WINDOWS version of nslookup, the type MUST go as first parameter like so:
nslookup -type=any _ldap._tcp.dc._msdcs.EXAMPLE.COM
nslookup -type=srv _ldap._tcp.dc._msdcs.EXAMPLE.COM

Also try just the regular "A" type
Also you can simply dig/nslookup the Active_Directory_DNS_domain_name and this will give you DC-IPs. (Because there's actually A records at that level.)


Switching operating systems for security

Absolutely not. Using more operating systems simply makes it more likely that you'll use an insecure system, and the attacker only has to wait until he gets lucky. In your example, you specify FreeBSD. Believe it or not, FreeBSD is really not that secure. It does not even have userland ASLR, which is considered one of the most basic of security requirements. If I was going after you, I would rejoice in the fact that you are jumping between systems. The same applies if you have a 0day exploit for a given system. In your very example, you specify Debian. Due to the Debian kernel configuration being so liberal, it enables an option which activates certain insecure legacy subsystems. I actually do have a 0day for it, but it does not work on the other systems you mentioned, as far as I know.

You say that the attacker would have to search for exploits each time. They don't, they just have to wait until you switch to a system that they can exploit. It's as simple as that.

In general, stick to one system. You are playing Russian Roulette each time you switch. Would you rather pull the trigger once, or many times? I would rather take a chance once, than take a chance over and over.


Is it safe to give credit card information by email?

It is a violation of their merchant agreement

All credit card merchants are required to conform to PCI-DSS which spells out rules for handing credit card data.  If you check the PCI DSS standards, you'll find the following:

  Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).

(The "PAN" is the CC number, a.k.a. Primary Account Number).

They should not be asking you to send credit card information over email if they are a legitimate authorized merchant.

See also this answer.

See also this PCI DSS cheat sheet (check the sidebar on page 2).

If the vendor loses PCI-DSS compliance (and you can lodge a complaint and possibly trigger a painful PCI-DSS audit by calling Visa corporation) then they will lose their ability to process credit card transactions.

P.S. No, it's not safe.


You won't know which are exploitable until you successfully exploit them.

By definition, the vulnerabilities identified are likely to be exploitable, otherwise they would not be identified as vulnerable.


Possible to send generated serialkeys using HTTP and get one right?

I can't comment on this specific scenario as there are unknowns such as rate-limiting by the server (see comment by JonasCz), entropy of the serial keys, etc. Here is a general approach to considering this when protecting your own systems.

Each of the ? in the serial key can take one of a number of values as defined by an alphabet. For example, binary alphabet limits them to [0,1], hex limits them to [0-F], etc. The cardinality (c) of the alphabet is simply the number of options; binary = 2, hex = 16, and so on. There are 20 ? so, best case for protection, we have c^20 possible choices from which to guess (assuming a good entropy source for their original generation).

Caveats

There are probably limitations on the actual choices in the form of checksums or authentication codes to validate a particular serial number. For example, the last 4 characters may be a truncated HMAC of the preceding ones, with security provided by the HMAC's key. There may simply be a non-cryptographic checksum which doesn't have a secret key.
A variant of the birthday problem - we're not looking to match a specific serial number. There are a set of true serial numbers and a set of guessed ones; an intersection of these sets that is not empty is a success.

Feasibility

Once we have reduced the search space given the caveats we can assess the feasibility of the brute-force attack with this excellent calculation. ("Thermodynamic Limitations" in Schneider B. Applied Cryptography pp. 157‐8).


How to reject e-mails spoofing your own domain targeting your employees at Office365?

You should modify your DNS settings to set up SPF for your domain, so email messages sent from an outside IP address are rejected. By the way, the recommendation you link to in your post aims to achieve the same result.

That would be the more effective technique. Failing to do so, your best bet would be to digitally sign all exchanged inter-domain emails and/or train your users, but I understand these are not always viable options.


Can DeepCorr's correlation technique de-anonymize all Tor users?

No, it cannot de-anonymize ALL Tor users.

(however it drastically narrows down the scope to proceed with successful de-anonymization)

Why, and what is flow correlation attack

Flow correlation attack is an attack where adversary intercepts network flows at various network locations "correlating" them using math statistics or machine learning methods (e.g. neural networks).

DeepCorr's setting consists of a network "with M ingress flows and N egress flows": DeepCorr listens to ingress flows, being closer to the group of users at the one end, and it just tries to figure out the moment when traffic starts leaving the circuit at another end. And it means "gotcha"!

Website != flow

  more and more people browse websites(many of those are simple websites) with similar sizes around the same time
  how can they tell the source of the traffic using size and timing alone when other flows have similar features?

DeepCorr does not do website fingerprinting (which is another class of attacks, as mentioned in the article), it just correlates a "flow A" to "flow B" at two different points of network.

Website similarities don't matter for successful correlation, DeepCorr operates with features of small packet sequences: sizes, times, flow direction (in/out), etc.

Still...

Correlation != de-anonymization

From the article:

  To be able to perform flow correlation, an adversary needs to observe (i.e., intercept) some fraction of flows entering and exiting the Tor network. The adversary can then de-anonymize a specific Tor connection...

I would say "but may not de-anonymize"... I mean that seems like a successful flow correlation attack doesn't automatically mean a successful de-anonymization. Correlation means "these users visited those group of sites" (but it drastically narrows down the set of users and increases de-anonymization probability).

Does Firefox generate additional patterns?

  Could it be the reason for why it worked so good for them? may be firefox generated some extra unique traffic that Tor browser wouldn't generate because of things like Ads and cookies?.

In my opinion there is no much difference between Tor and Firefox traffic flow.

Example: google.com

Firefox:
25 requests
1.31 MB / 677.67 KB transferred

Tor:
19 requests
1.39 MB / 498.30 KB transferred

Intuitively, I would say that both browsers generates some unique patterns of flows, and doesn't forget that website != flow.

Also seems like DeepCorr doesn't need too much of traffic to measure:

  "the correlated flows are 300 packets long for all the systems"...

Tor's hidden services

  Can this attack work against hidden services(version 3) as well?

I would say "why not": DeepCorr performs on traffic flows, it doesn't care whether the flow is "hidden", and hidden service is just another traffic flow. DeepCorr will correlate ingress and egress, and it is what it does.

P.S.: a few words about a possible countermeasure.

Countermeasure

As authors stated:

  "Our results suggest that (public) Tor relays should deploy a traffic obfuscation mechanism like obfs4 with IAT=1 to resist advanced flow correlation techniques like DeepCorr."

(IAT=0 doesn't help)

  "However, this is not a trivial solution due to the increased cost, increased overhead (band-width and CPU), and reduced QoS imposed by such obfuscation mechanisms... designing an obfuscation mechanism tailored to Tor that makes the right balance between performance, cost, and anonymity remains a challenging problem for future work."


Amazon advisory links to the original XEN advisory on which one can read:

  Systems running only x86 PV guests are not vulnerable.

So no problem for the PV instances. Regarding the HVM ones, Amazon explains that for performance reasons they managed to replace the HVM hardware drivers by the PV ones for storage and network operations (see PV on HVM).

Luckily enough, this vulnerability affects the storage emulation code. So most probable explanation is that this performance tweak actually also avoided VENOM vulnerability.


How protect mobile website against encapsulating into rogue native mobile app?

A user cannot trust a web page that is inside an app that they don't trust.

Therefore, if there was a UI redress attack against your website when using a particular app, then this would be the user's fault for trusting the application.

Furthermore, if an application developer wanted users to click something on your site using the phone, then they would simply code this into their application. They would not need the user to do it. Browsers within applications use a different set of cookies than the phone browser, so this would not affect any of the user's existing sessions. They would have had to log onto your site in the application's browser window, and at that point a rogue application could simply have harvested the credentials anyway.


A CRL distribution point has the following two requirements:

It must be highly available.
It must be accessible for everybody.

All three protocols can be highly available implemented but the second requirement makes HTTP the preferred choice.

The technological barrier of HTTP compared to FTP or LDAP is much lower.  HTTP can be accessed directly and via a proxy server. And the protocol is quite simple.

This does not apply to FTP or LDAP.

FTP can only be used in passive mode via a proxy server and the protocol is a bit more complicated and less standardized. Different servers generate different directory listings, which are sometimes incompatible to each other.

LDAP is well standardized but the implementation requires ASN.1 decoding, which is more complicated than HTTP. And there are no proxies available for LDAP in a perimeter security gateway of a typical company.


VPN through port 443 plus https more secure?

Let me start with a diagram!

You <------> Internet <-------> VPN <--------> Website (with HTTPS)

So the idea behind using a VPN is to securely transmit data to and fro on a public network.

So let me answer your questions:

Yes, your traffic will be tunneled through 443. So it is a secure tunnel.
Yes, you can use both your secure tunnel and the secure version of the website (HTTPS version). The HTTPS is basically between the website and the VPN endpoint.
It is definitely not an issue if you use the secure (HTTPS) version of the site through your secure tunnel. It doesn't really mean 3x more security. But it's definitely not a bad idea.

Hope this helps!


Use the & operator to combine two or more commands on windows (for unix use the ; operator).

If you need your command to be a string with no empty spaces, you could replace all space characters with their hex value  (\x20), so the dir command would be:

127.0.0.1\x20&\x20dir

Note that this method works only with the Python interperter.

An alternative that works well with Python's os.popen and on windows termilal would be to use a comma between your parameters and remove all spaces between the commands, eg:

127.0.0.1&dir,c:\users


Is there any reason not to issue 2FA recovery codes?

There are several implementations to bypass MFA in case you lose control over the "token" of one of the steps in the authentication.

I've seen the use of master passwords, recovery tokens, SMSs or phone calls to a backup phone number, emails, even postal messaging or faxes believe it or not, although the most frequent still remains to have a call with the operations team so that they can reset your account.

There are different problems with every one of them, I don't personally prefer one over the other as long as they are implemented in a right way and you also use them rightfully, so I'd advise you to first know what process your ISP uses to allow for account recovery and if it's secure then enable MFA.


What are the potential vulnerabilities in a SAML-based SSO approach?

The scenarios you mention would all be a problem with SAML and would be with just about any SSO method. If someone has root access on a server or has acquired the private keys, the security of the system is significantly if not completely compromised.

When you are delegating authentication, any compromise in trust can invalidate part or all of the assurance process. If a private key has been compromised, no assertion made by the idP can be trusted.

That said, if an attacker gains root privilege on a server, you probably have much bigger problems to deal with anyway. In the case of the RSA SecurID compromise, a number of people have tried to minimize the impact and are saying it will not kill SecurID. However, these people are overlooking that the fact that these hackers had such extensive access to do what they did would make it difficult for RSA to prove that we can trust their authentication products.


Online Government Elections System - Is it possible?

It is not known how to build an Internet voting system that will be verifiably secure and auditable.  Ron Rivest, Turing award winner and the R in RSA, has famously compared Internet voting to drunk driving: something you just can't do safely.
(By Internet voting, I mean voting over the Internet from client computers not controlled by election authorities, including return of voted ballots electronically over the Internet.)
The argument against Internet voting is a bit elaborate, but you can find details in the following articles:

If I can shop and bank online, why can’t I vote online?, David Jefferson.

A Security Analysis of the Secure Electronic Registration and Voting Experiment (SERVE), David Jefferson, Avi Rubin, Barbara Simons, and David Wagner.  Published in excerpted form in Communications of the ACM, volume 47, number 10, October 2004.

Attacking the Washington, D.C. Internet Voting System, Scott Wolchok, Eric Wustrow, Dawn Isabel, and J. Alex Halderman.  Published in FC 2012.

Don't miss the last paper.  It is a totally epic hack of an Internet voting system.


Is there any Online Certification that is worthy enough to get a Job as a Security Professional?

I would recommend taking a look at GIAC, CompTia and ISC2 certifications. If you are new to security (i.e. don't have 10+ years of experience in it) then starting with the CompTiA Security+ and moving to CEH will provide the credibility to your name.

Currently, the majority of the Information Security job postings require a mixture of certifications, experience and knowledge. If you don't have experience then you would need to compensate with certifications covering the area you are interested in and a lot of knowledge in that area. Side projects help greatly too.


Digital signatures and truly validating what was actually agreed to

If the other party to the document has any sense then they will quickly detect your nefarious behaviour. The whole point of digital signatures is that somebody can verify that the document and signature match.

Lets take an example. I am signing up to a contract on your website. You display the contract (document A) and I agree to it. You then change the terms of the document to your advantage (creating document B) and sign it. You then mail me the document for my record (I'm going to insist on this).

If you mail me document A then the digital signature will not match when I verify it - so my suspicions are aroused.
If you mail me document B then I see that the terms have changed and I challenge it.

The only way for you to send me document A and a signature that matches document B is to find a collision in the signing process, which if a proper process is followed, will be more or less impossible.


Overview
Modern hashing methods (which password_hash uses) are intentionally slow to make it impossible to do exactly what you are trying to do. Most are even resistant against parallelization with a GPU.
So if your goal is to speed up running through a 1 GB password list against a modern password algorithm, there is only one answer: there is no way to do so without running the whole thing on a gigantic computing cluster. Even then, a long enough password can be literally uncrackable.
You cannot accomplish what you are trying to do.
The Numbers
"You cannot do this" is the sort of statement that could use some hard numbers!
Hashing Rate
To crack a password we first need to know how fast we can test hashes.  I'm borrowing liberally from a real-life example when someone tried to crack the passwords in the Ashley Madison data dump using a cracking rig with 4 GPUs.  This is far better hardware than your typical home user will have access to. In that case bcrypt was configured to use a cost factor 12 (aka 4069 rounds of hashing), and the 4 GPU rig could only manage 156 hashes per second.  For a lower cost factor the hash rate rises quickly.  PHP uses 10 by default, which naively would result in a 4 times higher hash rate.  We'll round up for fun and pretend we manage to hit 750 hashes/second.
Hashes
Next we need to know how many passwords we're trying to crack.  Let's use a few examples: all possible 4 character passwords (numbers, letters, 10 special characters), all possible 6 character passwords, all possible 8 character passwords, or a 1Gbyte file filled with passwords.  This is how many passwords are in each list:

All 4 digit passwords: 72^4 = ~27,000,000 combinations
All 6 digit passwords: 72^6 = ~74,000,000,000 combinations
All 8 digit passwords: 72^8 = ~700 trillion combinations
A 1Gbyte file: ~100,000,000 passwords (assuming 10 bytes per password on average)

Hashing time
We know how many passwords we want to hash and our hashing rate (750/s), so now simple math tells us how long it will take to run through these lists with a top-of-the-line hashing algorithm:

All 4 digit passwords: ~10 hours
All 6 digit passwords: ~6 years
All 8 digit passwords: ~30,000 years
A 1 GB file: ~1.5 days

For more realistic numbers I roughly estimated the hash rate using one of the CPUs of my own machine, managing about 10 hashes per second.  Using that hash rate:

All 4 digit passwords: ~30 days
All 6 digit passwords: ~450 years
All 8 digit passwords: ~2 million years
A 1 GB file: ~115 days

Summary
Buy yourself a half dozen high quality GPUs and, presuming you use the default cost factor, you would be able to crack all possible 4 digit passwords in about a day.  Try doing just the 6 digit passwords and it will still take you years.  Your 1 GB file filled with passwords is harder to guess the time for, but realistically that will still take a few days to run through even with a bunch of GPUs helping you out.


Server not requesting for certificate in SSL handshake

In your second screenshot you see that the server sends its ServerHello and no subsequent Certificate Request... but no Certificate either. The server immediately proceeds with a ChangeCipherSpec, as if all the asymmetric crypto had already been done; and that's exactly the case. This is an abbreviated handshake in which both client and server remember the session secrets from a previous connection, and agree to use them again. When a session is thus resumed, there is no certificate, neither from the client, nor from the server. The client sends in the ClientHello a copy of the session ID from the previous session, and the server elects to indeed resume that session.

Ideally this is fine; if the previous session used an authentication that the server is comfortable with (e.g. a client certificate was indeed shown), then reusing the session implies reusing that authentication state. If the server is not comfortable with it, it may reject the resumption attempt (i.e. ignore the session ID as sent by the client, and proceed with a full, normal handshake) or enforce a re-handshake within the first. In a practical, realistic World, things are not always ideal, so the server code may accept to reuse the session, then decide that it should not have done so, and hide its shame by abruptly closing the connection.

SSL session parameters are cached in RAM, so restarting the client and/or the server process should empty such caches and at least allow you to obtain a clearer picture of what happens. It might also fix the issue altogether (that's the lightweight version of "try a reboot", a well-known cure for many Windows-related ailments).


If you have to disable the firewall in order to run a particular exploit then that test demonstrates the firewall is working effectively as a mitigating control. Which is generally the aim of a 'pen test'

Once you disable the firewall, many exploits are likely to work (I'm thinking zero days as well as all services with unpatched vulnerabilities) so it doesn't really add value.

Metasploit is a useful tool for automating simple or tedious exploits, but if you are at the point of needing to disable the firewall in order to run it, you are probably barking up the wrong tree.


The sole intention is to pair Windows 7 laptops to peripherals - human interface devices (HIDs) and printers - for field workers. Are
  there particular vulnerabilities to be concerned about?

Sure there is, not so much mouse interactions but say you have a bluetooth keyboard and I bluejack it, I can see everything you type, no different than a keylogger and its realtime and I don't have to capture and upload or anything, you are sending it to me on the fly.

  Is there a reliable way to configure what kind of profiles can be paired, to ensure only peripherals can be used?

You can use policies for that. On Windows machine (which I am assuming you are using based on the W7 comment) you can configure hardware restrictions using policy but again, not perfect as all BT devices don't properly classify their hardware. If you guys use the same devices are willing to do the work, you can hard code their hardware ids into the policies. Also you will need a pretty good robust version of Windows 7 (pro+), nothing budgetware (starter, home b/p).

  Is limiting discoverability the most important security measure? It
  seems if one forces the user to activate discoverability, most
  vulnerabilities are mitigated. Is this true?

Its the bare minimum effort in security and a must. A more robust pairing process has made interaction required to connect but being discoverable certainly makes the brute force easier because there is no time limit placed on it. So disabling discoverability will make it harder to bluejack but not impossible.

On a daily basis I see my neighbors smart tv, his mac, her ipad and so on show up and my computer tells me they exist, so you can imagine that if I was not an ethical hacker, they would not be happy campers. In fact I had to sit them down and tell them how to avoid broadcasting themselves like that. The wife was quickly dismissive about how much damage could be done until I showed her how long it took me to control her ipad, send her photos to her husband's email and have them see it all happen. Needless to say, I got a 6 pack of beer out of it :) and she is a convert. Sad part, I didn't even have to go black hat to do it, it was unsecured.


Delete saved login credentials username and password

If I'm not mistaken, the browser only saves the information if it is there when either the AJAX request is sent or the page changes.

Now I'm going to get slightly technical given that this isn't StackOverflow, but I won't go into too many details as you should post it there if you have code related questions, but given what you want the process could go like this for a state handling library like React:

the user presses submit.
you delay the execution of the page
change/login/ajax request.
you save the information to some state
(or a variable).
you set the values of the boxes to generic
"user" and "****".
You send the request and log in the user.

I'm not exactly certain if this will work with every browser, but I have noticed that websites tend to do something similar quite often. I will admit that this is highly dependent on the browser, but it always will be and I honestly don't think that browsers are smart enough to know the difference, and if they are, just place the submit button outside of the form (if preventDefault doesn't do the trick first).


What would be the repercussions in Information security, if someone found a way to factor large numbers quickly?

This is highly speculative, but, presumably, there would be much wailing and grinding of teeth. Then people would migrate to asymmetric cryptosystems that use elliptic curves. There would be some heavy business for CA; many SSH keys would have to be rolled over; and the PGP users would cringe first at the idea that anybody can impersonate them by forging signatures, then would cringe again when they notice that nobody actually bothers to do just that.

Switching to ECDSA would have the nice side-effect of killing off the last WinXP+IE setups, since the X.509 implementation used by WinXP+IE (for SSL connections to Web servers) does not support ECDSA.

Banking systems (EMV smart cards...) tend to use RSA so there would be a quickened renewal of cards and terminals, which would incur much grumbling from merchants, and would still take a couple of years to be effective.

A crucial point to understand is that while difficulty of integer factorization is what RSA security relies on, easy factorization does not immediately make the systems cease to work. If you can factor, say, Google's certificate RSA key, then you can impersonate Google, or decrypt passively recorded sessions, but you still have, as an attacker, to mount the eavesdropping or network spoofing system (which is not that hard to do, but not completely immediate either). I predict that the panic reaction would be much greater than the actual issues.


Popular website contains ad that triggers remote scan from botnet: what should I do?

Very interesting analysis.

Malicious ads/creatives are becoming more careful and precise in their targeting, meaning that they increasingly include code that makes a decision whether the malicious payload should be deployed or not, and if not, a legitimate creative is delivered instead.

So it is not impossible and in fact not even unlikely that the operator controlling this malicious deployment is targeting a specific geographical area at a specific time, and that as a result of that targeting, there was some signal that your IP address should be invited to join the party, which was hopefully foiled by your router or by other defenses.

In terms of actions, I have two to suggest.

Contact the website owner- the TV station. They have control over what kinds/providers of ads/creatives are allowed on their properties (inventory), and their reputation- not the advertiser or ad exchange- is impacted if malicious activity is detected by their customers or other monitors. So, definitely reach out to them with any details you can find.
Check that the machine you were browsing from is not compromised, e.g. is not listening on those udp ports, or has unusual processes running, or is issuing strange outbound command-and-control requests.


Apart from uploaded files, how else can 777 permissions on website files/folders be exploited?

It means that anyone can write to your folder , so someone can put (by using http PUT method curl http://myservice --upload-file file.txt)and call a cgi script that delete all your files or do whatever he/she wants.
Your index.php can also be delete by using:

  curl -X delete www.yoursite.com/index.php

But these two methods also depend on Apache configuration , which methods you have allowed and which are not allowed. You can see which methods a server allows , by using curl -I url command

Reference:

HTTP delete

The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.

A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity.


IIS client certificates: do I need client certificates mappings?

Under the mapping, you can map individual users to tokens which can then have permission to see things or do tasks (Admins, Personnel, Customers, etc). Without that you're just testing to see if a user has a valid certificate regardless of who he is.
You can authenticate the users further using mechanisms like form authentication but the mapping can automate this task for you.


There are GnuPG bindings for PHP, and GnuPG implements the OpenPGP format, which is about the only standard format covering ElGamal encryption. In any case, you are warmly encouraged not to design your own crypto protocol, and instead rely on existing standards like OpenPGP (these things are harder to make correctly than what it seems at first glance).


"Please Enter Nth Character" without HSM

Suppose that the question sent to the client can be about three characters: the server asks for (for instance) the 4th, 7th and 8th characters of the password.

Freeze time! At that exact point, the server has asked the question above, and will be able to verify an answer from the client. This means that in its complete state, there is enough information to tell whether a specific sequence of three character values is a correct answer or not. And it can tell that after investing a limited amount of CPU, say at most one second worth of computations on the server.

If that's software only, then the state can be recovered. We envision an attacker who hijacked the machine, so he can grab a full copy of the hard disk. At that point, the attacker has everything, so he can run an emulation of the server on his own machines. In particular, he can rewind the server to a known previous state.

Therefore, the attacker can now run an exhaustive search on the three character values, by trying and rewinding the emulated server.

This is unavoidable. Without dedicated uncloneable hardware (a HSM, namely), this kind of attack must work. This basically means that the password strength is that of a three-character password, i.e. nothing worth boasting about.


I am hesitant to comment on whether or not this specific situation is indeed a path traversal. I would need to play with the application to get a better idea.
However, considering your question:

Is this considered vulnerable to path traversal even if I am not able to get any files from outside of the web root?

Considering a true path traversal vulnerability, it is still a vulnerability even if you cannot break the barrier of the web root path. For instance, if you can include a web.config or similar file that resides at the web root but is not accessible directly with a web request, that can result in significant information disclosure.


You can test whether or not certain users do this without saving any additional data which might potentially weaken security. Just check what their previous password would have been when they follow this schema and compare that to the old hash.

When a user updates their password, create permutations of the new password by taking each digit in the password and decrementing it by one. Then calculate the hashes of these permutations and check if they match the hash of the old password. For example, when I change my password to Pas5word!14 you would calculate the hashes for

Pas4word!14
Pas5word!04
Pas5word!13

When one of them matches my old hash, you caught me.


Is it necessary to test all input parameters of a web application when testing its security?

Yes you need to test all parameters if you want to perform a good test. You may choose to use automatic vs manual testing depending on how critical the input variable is and where it is situated in the application. Note that while a certain input variable may seem non-critical it might leave attackers with a vector to get to more critical functionalities of the application (think of stored XSS)
Prioritize based on likelihood and impact on your business. If that vulnerability allows to execute commands or dump all contents of your database,including confidential information, you need to patch it as soon as possible. If it only allows access to public information (and it can't be abused to gain more privileges within the application or access to the underlying OS) then you might make it less of a priority (depending on what the other issues are you are prioritizing on)
I'm not sure what "input elements" are but if you mean parameters, you need to choose all. You can choose to pay more attention on some fields than others (depending on your budget/time)
It depends, you need to do what your client asks, obviously if your experience has learned you that certain variable are more susceptible than others, you might just give them a bit more attention. But I'd say you need to take the requirements of the client into account.

Even if a functionality is not considered critical, you always need to assess the impact your exploit has on the application and the information stored within the application. The opposite is true as well, if you have a critical functionality with an exploit, but you can't actually gain any valuable information from it, then you should make it less of a priority to fix it. So, the impact of exploiting a vulnerability  is important and not the criticality of the function you are exploiting. Prioritizing needs to happen based on impact.