I would say using headers is marginally more secure than a meta tag because: Some CSP elements such as report-to/report-uri are not supported in meta tags (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/report-to for that specific example and following the comment from Fire Quacker, this more general guidance https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html#3-content-security-policy-meta-tag ) Using headers allows a client to view the CSP via a HEAD request without loading the page. This could allow the client to decide not to proceed to a GET request if it did not like the CSP content (I appreciate this may be marginal security benefit, or maybe no real benefit at all in most cases)

No, this is not safe. The fact that your script-src includes 'unsafe-inline' and 'unsafe-eval' means that it provides no defense against Cross-Site Scripting. Furthermore, https: does indeed mean it allows inclusion of any source using https, such as https://attackercontrolleddomainfromwhichyoudefinitelyshouldneverexecuteanyjavascriptfrom.com

The usual approach - aside from just manually looking on all possible "page B"s for the injected content - is to inject content that will cause a unique, identifiable request to an external web server that you control, or at least can check the logs of. For example, you can inject

In a nutshell, SOP prevents code running on origin A from accessing the contents of origin B. A few specific examples: By default, a script running on a.com can't read the contents of b.com (it can send the request but won't be able to read the response). A script running on a.com can only access storage (cookies, local and session storage, etc.) for a.com, not for any other sites. If you have a page on a.com that contains an iframe with content from b.com, a script on the parent page (a.com) can't read the content, access most events, or even determine the current URL of the iframe hosting a b.com page. The reverse of the previous point: a page in an iframe (or frame, or pop-up, or object, etc.) can't read/modify/otherwise interact with the parent page if it's on a different origin (although as with the parent accessing the child, forcing the parent page to navigate is by default possible). By default, "complex" types of requests (with custom headers, or any but a few content types or methods, etc.) can't be sent across origins Without SOP, it wouldn't be safe to be signed into a website and then load content from any other site. Say you're signed into Facebook (don't necessarily have a FB tab open, but you have your FB cookie), and you browse to some news site. An ad (itself coming from a third origin) on the news site injects a script which tells your browser to make a bunch of requests to Facebook, thereby accessing your entire profile (with SOP, these requests would result in errors; the script wouldn't even know if you're signed in or not). The malicious script could then take arbitrary actions as you, so it can post stuff as you or replace everything on your profile or whatever (with SOP, it wouldn't be able to bypass the anti-CSRF protection that prevents making most cross-origin requests to Facebook, but without SOP it can see everything that the scripts on Facebook.com can see). Suppose you then open a new tab and log into your bank. Although the bank's session is short-lived, for its duration the malicious script would be able to see everything you can see on the bank site, and also take any action you could take.

In the "Dump" section at the bottom of x64dbg / x32dbg, you can right click and select "Find Pattern". In there you can search for ASCII, Unicode (UTF-16), or UTF-8 encoded strings in memory. Cheat Engine is another very useful tool for memory scanning, and may be more appropriate if you're trying to find a specific bit of memory with contents that change periodically. If the executable is simply checking that the string you entered matches a hard-coded one, you don't need to do anything - just enter that text and you win. If the executable is doing a more complex check you might want to just patch it to always pass regardless of whether the correct key is entered. This is usually done by finding the conditional jump that checks whether the key was valid (e.g. jz, jnz, jbe, etc.) and patching it to an unconditional jump (jmp) or removing the jump entirely (replace it with nop). For example, this code checks whether rax is zero, and if so it jumps to a failure case: 48 85 C0 test rax, rax 75 1F jnz fail Since you never want it to fail, you'd replace the jnz fail with a pair of nop instructions: 48 85 C0 test rax, rax 90 nop 90 nop Sometimes you'll run into the opposite case. This code tests if rax is equal to 4, and jumps to a success case if it is: 48 83 F8 04 cmp rax, 4 74 2A jz success Since you always want it to succeed, you can swap the jz out for a jmp: 48 83 F8 04 cmp rax, 4 eb 10 jmp success What the exact instructions are doing, which conditional jump you want to patch, and which type of patch you want to do is down to the specific situation. That's the challenge. You'll have to figure that part out on your own Press spacebar while highlighting an instruction in x32dbg or x64dbg to edit that instruction. You can then type in a replacement instruction. If you tick the "Keep Size" option, it will prevent you from accidentally overwriting the next instruction by entering a replacement instruction that is too large. If you check the "Fill With NOPs" box, it will pad the leftover space with bytes if you enter an instruction that encodes to something smaller than the instruction you're overwriting. Once you've made your changes you can save the patched copy of the file. Go to File -> Patch File (Ctrl+P) to see a list of the changes you've made. If you don't want to include certain changes, you can untick them. When you've picked which changes you want to apply, click Patch File in the bottom right to patch the file on disk.

It's always best to cover this during scoping calls, and if possible, get a list of owned assets, whether that's IP addresses domains, whatever. However, it's best to reach out to the client directly for clarification if you believe that asset is worth pursuing but are unsure if it's in scope. If this is also not an option, some things you can try: How did you find the asset? Can you make a direct connection back to something you surely know is in scope? Reverse Whois DNS lookups Certificates OSINT ^ Some ideas to keep the recon non-invasive and light.

A better question is: is there a reason not to make them HttpOnly? By default, you should mark all cookies as HttpOnly. If you discover that the cookies need to be read by on-page JavaScript, then you should investigate the reason for this requirement and weigh up the risks and benefits. If the risk is minimal or manageable, and the benefits are commensurate, then you should remove the HttpOnly flag. This goes for almost every security control. Your baseline approach should be as secure as reasonably possible by default. When you come across business processes and requirements that are impeded by those security controls, you should assess the situation (preferably with a threat modelling approach) and decide on an outcome. That might mean finding an alternative approach that fulfils the business requirement without changing the security controls. It might mean just accepting the risk. It might mean that you disable the security control that's causing problems, but applying mitigating controls elsewhere to lower the risk. As for tracking IDs in particular, they're generally benign enough that an attacker can't really use them for anything but privacy violation. Your average attackers generally aren't really interested in them. As for mitigations, you can't really mitigate the privacy violation part, because that's kinda the whole point of tracking cookies, but you can make attempts to protect against unintentional disclosure via plaintext HTTP connections (Secure flag) and XSS attacks (HttpOnly flag). Whether or not the potential privacy violation caused by a leaked tracking cookie is a risk to your users depends on the context - an online shop selling fancy tea bags has a very different risk profile to a website for victims of domestic abuse. That risk calculation and the resulting security decision is something that you have to make for yourself.

It looks like this is the apparmor conundrum. I had "stopped" apparmor, and retested, but it didn't seem to matter. Enabling APPARMOR_ENABLE_AAEVENTD so I could get logs on apparmor related denys: vi /etc/apparmor/subdomain.conf and updated the line: APPARMOR_ENABLE_AAEVENTD="yes" and restarted apparmor ori@myamdbox:/etc/apparmor$ sudo service apparmor restart I then reran the load_file("/etc/shells") above and the log spewed out: Oct 10 04:03:13 myamdbox kernel: [85739.145281] type=1400 audit(1381374193.268:132): apparmor="DENIED" operation="open" parent=1 profile="/usr/sbin/mysqld" name="/etc/shells" pid=22485 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=115 ouid=0 Tearing down the profile for a test worked, so it's certainly the culprit. To fix it simply I opened /etc/apparmor.d/usr.sbin.mysqld and added the line: ... /etc/shells r, And yep, it works. mysql> select load_file("/etc/shells"); +---------------------------------------------------------------------------+ | load_file("/etc/shells") | +---------------------------------------------------------------------------+ | # /etc/shells: valid login shells /bin/sh /bin/dash /bin/bash /bin/rbash | +---------------------------------------------------------------------------+ 1 row in set (0.00 sec) To do the opposite I need only find the reference in the apparmor config and remove it. Thanks Lekensteyn!

What you are thinking of doing is incredible similar to an existing attack known as the karma attack, made popular by the super fun Wifi Pineapple. The basic principle behind the attack is for the attacker to setup an AP that responds to the wireless probe packets clients send out when attempting to connect to a previously trusted AP. By responding to each individual packet on an individual basis, the attacker can force the client to connect to their rogue AP. When combined with a deauthentication attack, this is an incredibly effective tool for performing MITM attacks.

I faced the similar issue and after some trial and error, stumbled upon following solution. Stop the XAMPP control panel. Go to ..\XAMPP\mysql Find resetroot.bat and execute it. Proceed with entering random key when prompted. Restart XAMPP control panel. Now, when you try to connect to DVWA, the browser should land you on the Login Page. Solution: The bat file clears the passwords for 'root' and 'pma' user. Note: Make sure you have $_DVWA[ 'db_password' ]= '' in your config.inc.php file Worked for me! Good Luck !! PS: I encountered this issue after a successful DVWA site crawling using BurpSpider. i.e Everything was working fine and all of sudden I encountered mysql error. If anyone knows the root cause then explanation will be of much help.

Doing IT security properly implies grasping the fine details of how a computer operates; if you have that knowledge, then learning a programming language would be a matter of a few days at most. It is not, theoretically, strictly necessary to know any programming language to "do IT security", but potentially knowing them all is basically a requirement. There is a lot more to software development than simply "knowing the language", and we are not talking here about being able to design a big application, structure it, implement it, and being able to understand the code three months later. We are simply talking about the ability to write a 100 lines of code in order to experiment something. Every decent IT security specialist ought to be able to do that. (Conversely, I have met some IT security "specialist" who could not, and decency prevents me from expressing in accurate terms what I think of their competence.) Specific programming language, generally speaking, does not matter. They are all more or less the same -- I mean the programming, not the language. Ideally, learn three or four languages; then you will know them all. Potentially. Which is the important point. There are specific situations, though, which require a bit more programming knowledge. If doing pentesting on Web applications, you should have at least rudimentary knowledge of PHP, Javascript, SQL and C#/VB (for ASP.NET). To be taken seriously, be competent. To be competent, spend time on it. Computers in general, IT security in particular, are a field where practitioners spend a lot of time trying out things at home, on their own computers. Certifications are great when you want to be hired, because most people who will hire an IT security specialist are not IT security specialists themselves. For them, a certification is a kind of "proof of competence". In fact, a certification is a signal: it demonstrates that you were serious enough in your craft that you deemed it worth the effort to obtain the certification (learning the skills for the certification exam, spending the money on the certification, and, biggest effort of all, navigating the administrative task of actually obtaining the paper). Don't become an IT security specialist if your idea of fun does not include spending five hours reading through log files and network transcripts.

If integrity was not maintained, an attacker could alter Web pages in transit, and, for instance, modify Javascript code contained in these pages. Encryption, by itself, does not prevent relatively precise alterations, provided that the attacker has some idea about what the encrypted data is. In most Web contexts, the attacker can also register as a normal user, so he can see the structure of Web pages that normal users obtain. When the connection uses RC4, then a key-dependent pseudorandom stream is generated and XORed, bit by bit, with the data to encrypt. Therefore, if the attacker "guesses" that a given byte is the encryption of a 'A' (ASCII code 0x41) and wants to make it the encryption of a 'm' (ASCII code 0x6D), then he just has to XOR the encrypted byte with 0x2C (that's the XOR of 0x41 with 0x6D) to obtain another encrypted byte which, upon decryption, will yield a 'm' instead of an 'A'. Nothing else would be impacted; thus, with RC4 encryption, surgical alterations are easy. With a block cipher in CBC mode, things are less easy for the attacker, but he can still enact some evil: if he wants to modify a specific byte, he can, but this will mangle the previous block. Specifically, with a block cipher, the data is a sequence of blocks of 8 or 16 bytes (depending on the cipher: 8 bytes for 3DES, 16 bytes for AES). The attacker can modify at will a block, with surgical precision, provided that he knows the initial value of that block and does not mind changing the previous block into some uncontrollable random junk. Let's take an example. Suppose that a Web site has a login page, with an HTML form, which looks like this: Login: Password: I know it is ugly; it is just an example. When the user clicks on the "submit" button, the browser sends a POST request to the https://www.example.com/authenticate.php page. Now suppose that this page is CBC-encrypted with 3DES (8-byte blocks) and that the '.' of '.com' happens to be at the start of a block. The attacker can then XOR the previous 8 encrypted bytes (the bytes corresponding to .example) with the following: 00 01 0E 09 01 07 0D 5B On the victim's browser, the form will decrypt as: Login: Password: Where the "########" will be some random bytes. Provided that none of them is a zero or a double-quote (chances that this happens are low), then the browser will consider them as part of the target URL. The bad.fx domain is controlled by the attacker (the "fx" TLD does not really exist; feel free to replace with your favourite "TLD for Evil people"); the attacker's DNS gleefully redirects all requests for anything.bad.fx to his server's IP address; and the attacker bought (completely legally) a wildcard certificate for "*.bad.fx". When the user enters his password, his browser connects to the attacker-controlled Web site, does the SSL, is perfectly content with the attacker's certificate (assuming that none of the '#' is a dot; again, this is probable), and sends the password. Fortunately, SSL includes strong integrity protection, which prevents such attacks. With stream ciphers like RC4, and block ciphers in CBC mode, the integrity protection uses HMAC; newer versions of TLS can also use block ciphers in GCM mode, which integrates an equally good integrity protection. If the attacker attempted any of the stunts described above, the client (Web browser) would detect the alteration and protest and refuse to use the decrypted page. See the standard, section 6.2.3.

In any test that deals with critical systems, one would usually limit the test to low-risk operations, and avoid automated tools (e.g. Nessus) that might potentially harm the system. Specific to critical infrastructure, I would say the following: Schedule the test at a low demand point where applicable. Make engineers and other support staff aware of the test, and have them standing by to fix any issues quickly. Ensure that extra capacity / redundancy is planned during the test, where possible. Ensure that the testers are given an appropriate action plan that details how to deal with serious faults, or unresponsive systems. This should include emergency contacts. Despite this, there will always be a risk. It's something you have to deal with, and in a way it's a good thing. If the testers knock something offline by performing only low-risk actions, then you know that an attacker could do much worse. An accidental system crash during a planned test would suck, but not as much as widespread crashes due to malice when nobody is expecting it. Having it go down in the test scenario allows you to plan accordingly and make appropriate fixes.

To answer whether the sniffer module runs in promiscuous mode by default I am doing a test in my lab right now and will update it here when its done. UPDATE The answer finally comes out to be YES. The sniffer module does its capturing in promiscuous mode. To test I set up a win-xp-sp2 (10.10.10.101) vm on proxmoxVE (kvm virtual env). I added it to a bridge and added kali-linux (having ip 10.10.10.15) and a few more machines (machine-a 10.10.10.100 and machine-b 10.10.10.110) to the bridge. After running the exploit for netapi, I started the sniffer module on the target. Problem is linux bridges act as switches by default so again I ran into the same problem. I could only see the machines own traffic and broadcasts. Now to make a linux bridge act like a hub and not a switch, the aging for the bridges mac address table needs to be set to 0 (so it doesn't have a mac-address-table at all and traffic like broadcasts seding it to all members. For reference the command is brctl setageing 0. Once this was done, I pinged from machine-b to machine-a and here is what I got: 2013-08-28 21:22:03.000000 ARP, Request who-has 10.10.10.100 tell 10.10.10.110, length 46 2013-08-28 21:22:03.000000 ARP, Reply 10.10.10.100 is-at 2e:76:03:d3:b9:72, length 46 2013-08-28 21:22:03.000000 IP 10.10.10.110 > 10.10.10.100: ICMP echo request, id 11328, seq 1, length 64 2013-08-28 21:22:03.000000 IP 10.10.10.100 > 10.10.10.110: ICMP echo reply, id 11328, seq 1, length 64 2013-08-28 21:22:04.000000 IP 10.10.10.110 > 10.10.10.100: ICMP echo request, id 11328, seq 2, length 64 2013-08-28 21:22:04.000000 IP 10.10.10.100 > 10.10.10.110: ICMP echo reply, id 11328, seq 2, length 64 2013-08-28 21:22:08.000000 ARP, Request who-has 10.10.10.110 tell 10.10.10.100, length 46 2013-08-28 21:22:08.000000 ARP, Reply 10.10.10.110 is-at 22:06:8c:52:9f:c5, length 46 As you can see none of the above is supposed to be seen by the xp2 vm apart from the ARP who-has packets. Hence I can safely say that all packets which somehow reach the interface being sniffed are indeed recorded by the sniffer module and it is definitely running in promiscuous mode. General but important Information Switches send packets destined to IPs which you have an ARP entry on remote hosts for only. The remote host will send the packet with a destination MAC address based on their ARP table and a switch will only send it out the port where that MAC address is located. So even in promiscuous mode you will only see packets either explicitly destined to your IP or broadcasts which are sent out all ports connected to the switch in the same collision domain (VLAN and subnet). Hubs on the other hand mirror data received from anywhere to all ports irrespective of the destination MAC address since they are not smart enough to know which port the destination MAC address is available on. This leads to traffic between other machines also getting sent to you and this is probably the case you were hoping for, but from what you described the virtual switch acts like a semi-intelligent switch with a MAC table and the behavior is as described in the first paragraph.

There's several ways to go about this: First, monetary rewards are a great incentive, but if you can't afford them you'll need to provide them with other types of rewards. I think creating a special page on your site/application and creating a 'hall of fame' list of people that have found vulnerabilities. I'd also recommend that you consider running a CTF competition and include sections of your application's functionality in the CTF (or just make the CTF about who can find the most holes in your actual application). When you have a list of winners, post them publicly and keep them up so that people can reference it later. If you decide to do either of the above, make sure you publicize it and detail your intentions/desired outcome, as Evan suggests, posting it to a security mailing list might help attract attention. But as Terry says, if you build it, eventually someone will come and try to break it anyway regardless!

Many vulnerabilities occur as a result of smaller non-exploitable bugs which cause different parts of the software make false assumptions about each other. Returning user-input in a web applications response obviously suggests the possibility of cross-site scripting (XSS) attacks. These can be eliminated by proper input/output filtering/encoding. Applying a transformation like parsing the control characters you mentioned can however make your payload slip through the applied protections, for example the following pseudocode: transform(filter_xss($input)) can result in valid HTML/JS for the following input: test\x3cscript\x3ealert(1)\x3c/script\x3etest Multibyte characters can also be useful for exploitation. Also it seems possible that the user input gets parsed by some kind of command shell that would make more dangerous attacks, namely command injection possible. Based on the operating system you can try different metacharacters to achieve remote code execution, these are some for *nix: https://web.archive.org/web/20120810003039/https://www.cse.unsw.edu.au/help/doc/primer/node109.html

Not sure if it is what you are looking for, but you could try Oxygen Forensic (http://www.oxygen-forensic.com/en/). It's a powerful tool and it have a very complete trial version.

To properly test your appliance and website I would get some pentesters involved and hand them over the rule set you are currently using. This will assist them in trying to create custom malicious payloads which would traverse the WAF for which you can then create additional rules. I would also make them test the application which you are protecting without a WAF, as this will purely test the security of your application. (A WAF is not a miracle to protect a badly secured web application) If you don't have a budget have a look at Burp (not free) or ZAP and gather some custom payloads from the internet yourself to fuzz your application with.

There's no way that a pentester can 100% assure that data will not be modified or deleted, in the same way as they can't assure that system availability won't be affected (I've knocked systems over with a port scan or a single ' character). as you say a web crawler can delete data from a system if it's been set-up badly. I'd say that what should be said is something like "every care will be taken to ensure that the testing does not negatively affect the systems under review and no deliberate attempts will be made to modify or delete production data or to negatively affect the availability of in-scope systems. However with all security testing there is a risk that systems will be affected and the customer should ensure that backups of all data and systems are in place prior to the commencement of the review"

This won't work with reverse payloads unless you can do portforwarding on the system which is NATing your traffic. Hence it's better to generate a payload which allows you to connect to it rather than a payload which connects back (but if your target is also using NAT, then this becomes obsolete as well). For instance: shell/bind_tcp This does give problems if there is a firewall between you and the target. Best thing to do is take away the NAT completely if possible. In your case this seems quite difficult...